Website Migration Checklist for Indian Small Businesses: SEO, DNS, Email & Forms

1. First identify which kind of migration you are doing

A hosting move, a domain move and a redesign are not the same project. The correct checklist depends on whether the public URL changes. Google Search Central separates a hosting change with no URL changes from a site move where URLs change, and the operational steps differ.

A host-only move keeps the same domain and page paths—for example, https://example.in/about remains https://example.in/about while the site moves to a different host or CDN. A domain move changes the hostname—for example, example.in to example.com. A URL-structure move changes paths—for example, /services/gst to /gst-registration. A platform redesign may keep URLs unchanged, change them, or introduce both a new platform and a new domain.

Write down the exact change before choosing a launch method. If only the host is changing, you normally update the web-serving DNS records and preserve the URL structure. If the domain or paths change, you also need a URL mapping, permanent redirects and additional Search Console checks.

• Host-only move: same domain and same page URLs; focus on copying, testing, DNS cutover and crawl monitoring.
• Domain move: new hostname; add one-to-one redirects, verify both Search Console properties and use Change of Address where eligible.
• URL or CMS redesign: paths may change; map every valuable old URL to its closest relevant new destination.
• Combined move: new host, domain and redesign; separate the work into a written inventory so DNS, redirects, content and analytics are not missed.

2. Build a migration inventory before anyone edits DNS

The most expensive migration mistakes often begin with an incomplete inventory. Do not rely only on the homepage or a developer's memory. Export the current sitemap, crawl the old site, review Search Console landing pages and record URLs that receive organic traffic, backlinks, enquiries, payments or customer support requests.

Include operational dependencies as well as public pages. A business website may use separate services for email, contact forms, CRM notifications, payment gateways, appointment booking, analytics, advertising pixels, domain verification and file downloads. These may depend on DNS records or environment variables that are not part of the website code.

Create one owner for each workstream: content and URLs, DNS and domain, hosting and deployment, email and forms, analytics and testing. A small team can assign several workstreams to one person, but each task should still have a named owner and a recorded pass/fail result.

• Export the current sitemap and record every indexed or commercially important URL.
• List page titles, canonical URLs, status codes, images, PDFs and downloadable files.
• Record domain registrar, authoritative nameservers, DNS provider and current zone records.
• Inventory A, AAAA, CNAME, MX, TXT, SRV, CAA and NS records where present.
• Record email provider, mailbox routing, SPF, DKIM, DMARC and domain-verification records.
• List forms, SMTP settings, CRM destinations, payment callbacks, webhooks and booking tools.
• Export analytics and tag configurations, Search Console verification methods and advertising pixels.
• Save current hosting details, environment variables, scheduled jobs, database versions and access owners in a secure handover document.

3. Back up the old site and prove the backup can be restored

A backup is useful only if the business can restore it. Save the website files, database, uploaded media, configuration, redirect rules and relevant DNS zone information. For a hosted platform, use its documented export or backup method and confirm which parts are excluded.

Take a fresh backup before the final content freeze or database sync. If the website receives orders, bookings or enquiries while the new version is being prepared, decide how changes made during the build will be copied across. A static copy may be sufficient for a brochure site; a store or customer portal may need a final database export, order reconciliation or a short write freeze.

Keep the backup separate from the new production environment and restrict access. Do not place database dumps, API keys or customer exports in a public repository or an unprotected shared folder. Test a restore in a non-production environment before relying on it.

• Back up source files, database, media, uploads and configuration.
• Record the backup date, owner, storage location and restore instructions.
• Test a restore on a staging environment and confirm pages, images and records are readable.
• Plan how orders, enquiries, bookings or account changes created during the migration will be reconciled.
• Keep the old hosting account active until the new environment has been checked and the rollback window has been agreed.

4. Map old URLs to relevant new URLs

If a page URL changes, create a row for the old URL and its intended new destination. Prefer to keep a URL unchanged when the page still serves the same purpose. When a path must change, map it to the closest equivalent page—not automatically to the homepage.

Google recommends server-side permanent redirects, such as HTTP 301 or 308, when a URL has permanently moved. Redirect chains add latency and complexity, so send an old URL directly to its final destination. A redirect from an old service page to an unrelated homepage can confuse visitors and may be treated as a soft 404.

A simple mapping example is: /about-us to /about; /services/gst-registration to /services/gst; /old-contact to /contact. These are illustrative paths only. Use the real old and new URLs from the site inventory, and check trailing slashes, uppercase/lowercase variants, query parameters and language paths where relevant.

• Create a one-to-one mapping for every important old URL that has a replacement.
• Preserve the existing URL when the content and purpose have not changed.
• Use a server-side 301 or 308 for a permanent move where technically possible.
• Avoid redirect chains, loops, blanket homepage redirects and irrelevant destinations.
• Test old URLs with and without trailing slashes and check query-string behaviour.
• Update internal links to point directly to the new canonical URLs rather than relying on redirects.

5. Prepare and test the replacement site before launch

Build the replacement on a staging URL or temporary hostname while the current site remains available. Google recommends copying and testing the new site before changing DNS. A temporary hostname can help teams review the site without interrupting visitors.

Protect staging from accidental indexing. Use an appropriate noindex directive or access restriction while it is private, and make a launch checklist item to remove the temporary noindex rule and any crawl blocks before production. Do not use robots.txt as a substitute for canonicalisation or as the only way to keep a staging site out of search.

Test the full customer journey, not just whether the homepage loads. Check navigation, mobile layout, forms, file downloads, login, checkout, payment callbacks, email notifications, accessibility basics and error pages. Test with realistic devices and browsers, and keep a list of defects with owners.

• Review every priority page, image, PDF and downloadable file.
• Test mobile navigation, page layout, keyboard operation and readable contrast.
• Submit test enquiries and confirm they reach the correct inbox or CRM.
• Test account creation, login, checkout, payment return URLs and order notifications where applicable.
• Check page titles, descriptions, canonical tags, structured data and internal links.
• Remove staging-only noindex or access restrictions only when the production site is ready to launch.

6. Copy the DNS zone carefully—website records are not the whole domain

DNS is shared infrastructure for the website and other domain services. An A or AAAA record can direct a hostname to an IP address; a CNAME can point a hostname to another hostname; MX records route email; TXT records are commonly used for domain verification and email authentication; and SRV records can support particular services. The exact set depends on the business.

If you are changing only the web host, you may need to change the web-serving A, AAAA or CNAME records while leaving email routing and verification records untouched. If you change nameservers, the new DNS provider becomes authoritative, so the full zone must be recreated or imported—not only the website record. Missing MX or TXT records can disrupt email or verification even when the website itself works.

Cloudflare documents that only A, AAAA and CNAME records can be proxied. MX and TXT records are DNS-only, and CNAME records used for purposes such as ownership verification should not be proxied. Do not blindly turn every record orange-cloud or copy an example IP address from a tutorial; use the exact values required by the current hosting and service providers.

• Export the existing DNS zone or take a complete record-by-record snapshot before changing nameservers.
• Confirm the exact apex and www records required by the new host from its domain dashboard.
• Preserve MX records and all current SPF, DKIM, DMARC and verification records unless the relevant provider instructs you to change them.
• Check SRV, CAA and other service-specific records where they exist.
• Set proxy status according to the record's purpose and the provider's compatibility guidance.
• Compare the old and new DNS zones before switching authority, then test website and email resolution separately.

7. Keep business email and website form delivery working

Website hosting and business email are often separate services even when they use the same domain. A host-only move should not normally require changing MX records if email remains with the same provider. However, changing nameservers without copying the old MX and TXT records can break mail routing or authentication.

Website contact forms are a separate path. A form may send through SMTP or an email API, use a verified sender domain, call a serverless function or write an enquiry to a CRM. Test the form after migration and confirm that the submission is saved, the notification is delivered and the customer receives the expected confirmation. A successful button click is not proof that the enquiry reached the business.

A Reddit web-hosting discussion about email failing after a hosting change describes missing or altered MX and DKIM/SPF records as likely causes. That is an individual troubleshooting thread, not a universal diagnosis, but it illustrates why the email record inventory should be part of the migration plan.

• Confirm where mailboxes are hosted and preserve the provider's current MX records.
• Retain SPF, DKIM and DMARC records and verify them against the mail provider's current instructions.
• Check whether the website sends mail through SMTP or an email API and update credentials securely if required.
• Submit a test enquiry from an external email address and confirm receipt, reply path and CRM record.
• Test password resets, order confirmations, booking notices and other transactional messages.
• Do not assume that changing the website A record requires moving the email service.

8. Verify HTTPS, domain variants and hosting configuration

Confirm that the apex domain and the chosen www or non-www hostname are attached to the correct project. Hosting dashboards often show the exact A or CNAME records required for a particular project; use those values rather than a generic example from an old tutorial.

For a Vercel-hosted site, its current custom-domain guide explains how to add the domain, inspect the required DNS records, verify the configuration and check SSL certificate provisioning. It says Vercel automatically provisions SSL after DNS verification succeeds. Other hosts have different steps, so follow the documentation for the actual provider.

Choose one canonical hostname and redirect the other variant consistently. Check HTTP to HTTPS behaviour, certificate validity, mixed-content warnings, trailing slash rules and redirect loops. If the new host uses a CDN or reverse proxy, verify the origin and proxy configuration together.

• Attach the apex and www hostnames to the intended project and choose the preferred canonical host.
• Use the exact DNS values shown in the provider dashboard.
• Verify that the certificate covers every public hostname and that HTTPS loads without warnings.
• Redirect HTTP and non-preferred host variants consistently to the preferred HTTPS URL.
• Check that no page links to an old staging hostname, temporary domain or HTTP asset.
• Confirm that domain verification and Search Console ownership remain valid after the move.

9. Protect search visibility when URLs or domains change

A migration does not guarantee that rankings will remain identical. Google says that a hosting change with unchanged URLs can cause a temporary crawl-rate fluctuation; the important requirement is that Googlebot can reach the new infrastructure without serious errors or slowdowns. When URLs change, Google recommends a clear redirect plan, updated canonicals, redirect testing and a new sitemap.

After the move, the new pages should use self-referential canonical URLs where appropriate, and internal links should point directly to the new preferred URLs. The sitemap should list the canonical URLs you want discovered. A sitemap is a helpful but weaker canonical signal than a redirect or rel=canonical annotation, so it cannot repair a broken URL map by itself.

Use the Search Console Change of Address tool only when moving from one domain or subdomain to another, after redirects are in place and both properties are verified. Google says the tool is not for a hosting move with unchanged URLs, HTTP-to-HTTPS, or a www/non-www change within the same domain. Google recommends keeping domain-move redirects for at least one year.

• Keep important URL paths unchanged where possible.
• Deploy and test permanent redirects for every changed high-value URL.
• Update canonical tags, internal links, hreflang where used and structured-data URLs.
• Regenerate the sitemap so it contains only current canonical URLs and submit it in Search Console.
• Check robots.txt and page-level robots directives; remove accidental noindex and crawl blocks from production.
• Use Change of Address only for an eligible domain or subdomain move, not for a host-only change.
• Keep old-domain redirects for at least one year and longer when users or crawlers still reach them.

10. Reconnect analytics, advertising and conversion tracking

A new site can load perfectly while measurement silently stops. Record the analytics property, tag manager container, pixels, consent settings, event names, cross-domain settings and UTM conventions before migration. Copy the correct configuration into the new site and remove duplicate tags that were added by both the platform and a plugin.

Test important events with the provider's debugging tools. For a lead form, count a lead only after the backend confirms that the enquiry was accepted or saved; do not treat every click on a submit button as a successful lead. Keep personal details such as names, email addresses and phone numbers out of analytics event parameters.

Compare the first post-launch day with the baseline, but allow for reporting delays and changes in attribution. Reconcile analytics events with actual enquiries, orders or CRM records rather than assuming the analytics total is the exact business outcome.

• Confirm GA4, Google Tag Manager, Search Console and advertising tags are present once—not duplicated.
• Test page_view, form success, purchase, booking and other agreed conversion events.
• Check consent and privacy settings with the appropriate professional for the business and jurisdiction.
• Preserve UTM campaign naming and cross-domain settings where relevant.
• Compare event counts with CRM, order or booking records after launch.
• Keep personal information out of analytics event names, URLs and parameters.

11. Test e-commerce, payments and third-party integrations

For an online store, a successful homepage load is only the beginning. Test product pages, variants, inventory, cart, checkout, payment initiation, payment success and failure, order confirmation, refund and cancellation flows. Confirm that webhook endpoints and callback URLs point to the new environment and that secrets are stored in the correct environment variables.

Run a controlled low-value test transaction where the payment provider and business process allow it, then reconcile the order and settlement. Do not use real customer data or leave test orders mixed with live orders. If the site uses shipping, tax, invoicing or marketplace integrations, test those paths with the relevant provider's sandbox or documented test method.

• Check catalogue, variants, stock and price display.
• Test cart, checkout, payment success, payment failure and cancellation.
• Verify webhook signatures, callback URLs and environment-specific secrets.
• Confirm invoice, shipping, refund and order-notification workflows.
• Check customer account access and password-reset emails.
• Record the test transaction and remove or reconcile it before normal operations.

12. Use a controlled cutover and write down the rollback trigger

Choose a low-risk launch window based on customer activity and the team's availability—not simply a convenient calendar date. Freeze content or record the final changes, take the final backup, sync any new records, confirm the new site is ready and then update the required DNS records. Keep the old site available while caches and users move to the new destination.

Google's hosting-move guidance recommends lowering DNS TTL in advance—its example suggests a few hours at least a week before the move—so cached records can refresh sooner. This is a planning suggestion, not a promise that all resolvers will switch at the same time. If you use Cloudflare, its proxied records have an automatic TTL and cannot be edited like ordinary DNS-only records; check the provider's current behaviour before planning the cutover.

Agree on rollback triggers before launch. Examples include widespread 5xx responses, broken checkout, failed enquiry delivery, missing email routing, invalid certificates or critical data mismatch. The rollback method depends on the architecture: it may be restoring the previous DNS target, reassigning a domain, reverting a deployment or restoring a database. Do not switch DNS back without understanding whether new orders or records were created after launch.

• Choose a launch window with technical and business owners available.
• Freeze or record final content and data changes; take a final backup.
• Confirm the new host, domain, certificate, forms and key integrations are ready.
• Change only the records required for the move and record the exact change time.
• Monitor the old and new environments during propagation and keep the old environment available.
• Use a written rollback decision tree and reconcile orders or enquiries before reversing a database change.

13. Monitor the first day, first week and first month

Immediately after launch, test the site from more than one network and device. Check the apex and www variants, priority landing pages, forms, login, checkout and email. Review server or edge logs for 404s, 5xx errors, redirect loops and blocked requests. Use Search Console URL Inspection for important pages and watch indexing, crawl and sitemap reports.

During the first week, compare old and new URL requests, organic landing pages, form submissions, orders and customer complaints. Fix incorrect redirects and internal links at the source rather than adding another layer of redirects. Keep a change log so the team can connect a traffic or conversion change to a specific release.

At the end of the agreed rollback period, decide whether the old hosting account can be closed. Do not shut it down merely because the new homepage works; confirm that the new environment serves users and crawlers consistently and that required backups, redirects, mail and integrations are stable.

• First day: test core journeys, certificates, DNS, forms, mail and critical pages.
• First week: review Search Console, 404s, 5xx logs, redirects, indexing and conversion records.
• First month: compare organic landing pages, enquiries, sales and support issues with the pre-migration baseline.
• Keep redirects and the old domain available according to the migration plan.
• Close old hosting only after the new site and all dependencies are confirmed stable.

14. Compare migration quotes by scope, not just headline price

Public provider pages show that a simple hosting transfer and a full website redesign are different products. ZoopCoder advertises a website migration service at ₹1,999; Altechmind lists a standard cPanel-to-cPanel move at ₹1,999 plus GST; Smarteer publishes redesign packages starting at ₹8,000 and higher tiers that include broader design or SEO work. These are provider-published offers observed on 15 November 2026, not market averages, independent quality ratings or guaranteed delivery terms. The scope and exclusions differ.

Before accepting a quote, ask whether it includes a full backup and tested restore, database and media transfer, email and DNS inventory, SSL, redirects, Search Console, analytics, form testing, payment testing, post-launch monitoring and rollback support. Ask who owns the domain, hosting account, source code and DNS credentials after handover. A low-cost transfer that excludes email, redirects or post-launch troubleshooting may not solve the business problem.

For a new website rather than a migration, compare the required pages, content, form workflow, integrations and maintenance scope with the provider's actual statement of work. FIN.SWITCH's GROW Website service is a website build option; a migration or platform move should be scoped separately before any delivery commitment is made.

• Request a written list of included pages, files, databases and integrations.
• Confirm whether DNS, business email, SSL and domain verification are included.
• Ask for the redirect map and a post-launch 404 report.
• Confirm testing for forms, CRM, payments, analytics and customer notifications.
• Keep domain, DNS, hosting and payment accounts under the business owner's control.
• Get exclusions, taxes, support period, rollback responsibilities and acceptance criteria in writing.

15. A practical migration acceptance checklist

Do not close the project because the new homepage looks correct. Use a signed acceptance checklist that records the evidence for each important item. If a test fails, assign an owner and due date before the old environment is retired.

• The old site, database, media and DNS zone have a dated backup and tested restore.
• The URL inventory and old-to-new mapping cover all important pages.
• The replacement site has been tested on desktop and mobile before DNS cutover.
• The production domain resolves to the intended host and the TLS certificate is valid.
• MX, SPF, DKIM, DMARC and domain-verification records remain correct.
• Contact forms, CRM notifications, password resets and transactional email work.
• Permanent redirects resolve directly to the correct destination without loops or long chains.
• Canonical tags, internal links, sitemap and robots directives reflect the production URLs.
• Search Console and analytics are verified and key conversion events have been tested.
• E-commerce checkout, payment callbacks, order emails and refunds have been tested where relevant.
• The rollback trigger, decision-maker and data-reconciliation method are documented.
• The old host and domain redirects remain available for the agreed monitoring period.

Frequently asked questions

Does changing website hosting affect SEO? A host-only move keeps the public URLs unchanged. Google says crawl rate can fluctuate temporarily, but the new infrastructure should remain accessible and responsive. A domain or URL move needs redirects and additional Search Console work; no provider can guarantee that rankings will remain identical.

Do I need the Search Console Change of Address tool? Only for an eligible move from one domain or subdomain to another, after redirects are active and both properties are verified. Google says not to use it for host-only moves, HTTP-to-HTTPS or www/non-www changes within the same domain.

Will changing my website host stop business email? It should not if email remains with the same provider and the relevant DNS records are preserved. If nameservers change and MX or TXT records are omitted, mail routing or authentication can fail. Website form delivery must be tested separately.

Should I change nameservers when moving hosting? Not necessarily. If the DNS provider is staying the same, changing only the web-serving records may be enough. Change nameservers only when the architecture requires it and after copying and checking the complete DNS zone.

How long should old-domain redirects remain? Google recommends keeping redirects for at least one year for a domain move, and longer if users or crawlers still reach old URLs. Keep the old domain registered so the redirects can continue to work.

How much does website migration cost in India? There is no single official migration fee. Public provider offers range by scope: a simple hosting transfer is not the same as a redesign, platform change, e-commerce migration or SEO migration. Compare the written deliverables and exclusions rather than assuming all quotes are equivalent.

Can I launch the new site and fix SEO later? It is safer to test redirects, canonicals, robots rules, sitemap and internal links before launch. Fixing them later can leave visitors and crawlers reaching missing or duplicate URLs during the most sensitive part of the move.