Website Migration Checklist for Small Businesses

A website migration is easier to review when “the site has moved” is broken into specific checks. For a small business, the important question is whether customers can still find the right pages, send an inquiry or finish an order after the switch.

Use this checklist to define the work with your developer and host. A host transfer, domain change and platform rebuild need different plans. Mark each item as included, excluded or requiring another provider so nobody assumes a task belongs to somebody else.

1. Define exactly what is changing

• Current and destination hosting, with account owners identified.
• Whether the domain, page URLs or content management system will change.
• Whether the move includes design, copy or functionality changes.
• Who controls the domain, DNS, email and payment accounts.
• The features that must be tested and the person who approves launch.

For example, moving a five-page WordPress site to another host may leave every public URL unchanged. Rebuilding a booking website on a new platform can require new templates, forms and integration work. Those projects should not share the same unchecked assumptions.

2. Inventory pages and customer journeys

List service pages, articles, downloads and other useful URLs. Include pages used in advertisements, directory profiles and email signatures. Identify which forms, bookings or checkout steps bring business inquiries or orders.

Create a short test record for each important journey: starting page, action, expected result and where the result should arrive. “The contact page loads” is different from “a test inquiry reaches the correct inbox.”

3. Make a backup that covers the actual website

A WordPress recovery copy needs the relevant files and database. Confirm where the copy is stored, who can retrieve it and what date it represents. Keep the recovery record separate from assumptions about a hosting provider’s default backups.

Before authorizing cutover, ask how the site would be restored and whether the destination copy has been tested. The WordPress backup guidance explains the distinction between website files and database data.

4. Protect URLs and search information

Preserve useful page addresses wherever the project allows it. If addresses must change, map each important old URL to its relevant new destination. Check page titles, descriptions, internal links and canonical URLs on the destination.

Keep this task separate from a broad promise that rankings will stay unchanged. Search visibility is checked through working pages and available search reports. For a domain or URL change, use Google’s site-move guidance as part of the technical plan.

5. Separate website hosting from business email

Find out where email actually runs before changing nameservers or DNS records. Record the existing mail settings and identify who will preserve or replace them. Moving website files does not automatically transfer mailbox contents.

After the agreed switch, test sending and receiving business email through the real setup. Include contact-form delivery in the same review, because a website can appear healthy while its inquiry messages fail.

6. Review integrations and active transactions

List payment gateways, shipping tools, appointment systems, analytics and other connected services. Confirm whether any callback URLs, allowlists or licences depend on the current domain or environment.

For an active store, agree how orders and stock changes will be handled during the move. Identify the authoritative data source and any temporary freeze or final synchronization step. Never discard new transactions by treating an old database export as the latest store.

7. Test before and after cutover

• Important pages, menus and media render correctly.
• Mobile layouts and long headings remain usable.
• Forms deliver to the agreed destination and show a clear success state.
• Relevant checkout or booking journeys work in an agreed test mode.
• HTTPS, redirects and public URLs behave as intended.
• Production indexing settings match the approved launch plan.

Record actual test outcomes and unresolved items. Assign someone to decide whether a failed check delays launch. Keep the old hosting environment available for the agreed recovery window, then confirm cancellation responsibilities and renewal dates.

Decide which checklist applies to your move

Before turning the checklist into a project, separate the changes you intend to make. A hosting transfer moves the existing website into a different server environment. A domain move changes the address customers use. A platform rebuild recreates the site in a different system. A redesign changes presentation and may also change navigation, content or functionality. One project can contain several of these changes, but each needs its own acceptance checks.

Write down the source and destination for each part. For example, “WordPress on the current host to WordPress on the destination host, same domain” tells the developer more than “migrate my website.” Add whether email stays with its current provider, whether the store keeps taking orders and whether any pages will be removed. This makes it possible to identify work that belongs to the host, the developer or another specialist.

Avoid using a checklist to imply that every platform supports a direct transfer. Some builders export only parts of their content. Their page layouts, booking tools or store features may require replacement rather than copying. Request an assessment of the exact platform and integrations before agreeing to a method or delivery date.

Build a URL inventory that includes more than the menu

The main navigation is a useful starting point, but it rarely lists every important address. Include articles, campaign landing pages, product categories, downloads and pages linked from external profiles. Check the website’s content-management records and available search or analytics reports for useful URLs that receive visits without appearing in the menu.

A simple inventory can contain the current URL, page purpose, whether it will remain, the intended destination and the person responsible for reviewing it. If there is no useful replacement for a page, document that decision instead of sending every removed address to the homepage. A service page and a homepage answer different visitor needs.

Keep downloads and media in the review when people link to them directly. A brochure mentioned in an email campaign can remain important even if it has no dedicated landing page. Confirm whether its URL will be retained or whether links need updating. Use the same record during the destination test so you can compare expected and actual behavior.

Record the information needed to rebuild access

A migration depends on several accounts, and they may belong to different people. Identify who controls the domain registration, hosting, DNS, email service and any essential integrations. Also identify who owns paid theme or plugin subscriptions. The ability to sign into WordPress does not necessarily provide access to those other systems.

Ask the provider what access is required for the agreed method and when it is needed. Keep account ownership with the business wherever appropriate. Share credentials through an agreed private channel, and use permissions suited to the work rather than putting passwords in a public inquiry form, spreadsheet or screenshot. Access handover should be a defined task with a named owner.

Include recovery access in the plan. If a former developer receives all account recovery messages, a launch problem may become an access problem. Resolve ownership and recovery arrangements before the cutover window. After delivery, review temporary access and confirm that the business can still manage its domain, host and content independently.

Review the destination hosting before transferring data

Compare the destination environment with the website’s current requirements. The review may include supported PHP versions, database compatibility, storage, upload limits and the server features used by the existing site. Ask whether the planned package supports the site’s important integrations and whether there are restrictions that affect the migration method.

Do not assume that the largest advertised storage figure is the only relevant specification. A store, a brochure website and a resource library place different demands on their hosting. A package can have enough storage while still introducing limits that complicate scheduled jobs, large imports or a particular application. Identify the practical requirements before purchasing or switching plans.

Record who will create the destination environment, configure HTTPS and confirm that the website can run there. If the provider offers a temporary address or staging facility, agree how it will be used for review. A preview that shows only the homepage is not sufficient evidence that the entire transferred website is ready.

Make the backup and recovery record usable

Treat the backup as a recoverable version of the website, not simply a download that exists somewhere. Record when it was taken, what it contains, where it is stored and who can retrieve it. For WordPress, include the relevant website files and database. Identify whether content or transactions can change after that copy is created.

Ask how the backup will be restored if the destination fails an important check. A recovery process can depend on hosting access, storage, the backup format and the tools used to create it. A restore test in an appropriate environment can reveal those dependencies before a live problem occurs. Agree who performs that test and how its result will be recorded.

Keep the recovery window clear. If the old host remains available, record when it may be canceled and who has authority to cancel it. If the project changes the domain, distinguish retaining old-domain redirects from retaining the old website environment. Neither decision should be left to an assumption made after launch.

Protect content and editorial details

Check more than the visible page paragraphs. Depending on the site, useful content can include article dates, author information, categories, product descriptions, downloadable files, image descriptions and metadata. List which fields need to survive the move and where they will be managed on the destination platform.

Review formatting with representative pages. A short service page may transfer cleanly while a long article with tables, embedded videos or forms needs attention. Use examples from different page types instead of judging the entire content library from one successful page. Record any unsupported feature and agree whether it will be rebuilt, replaced or removed.

For a redesign, separate approved editorial changes from accidental content loss. If the business wants shorter copy or different service names, keep a record of those decisions. When a page is missing after launch, the team should be able to tell whether it was intentionally consolidated or was overlooked during implementation. That distinction helps resolve issues without undoing approved work.

Review redirects as a visitor journey

When URLs change, ask what a person following each old address should see. The destination should match the original purpose as closely as practical. A visitor looking for a specific service should reach that service or an appropriate replacement, rather than a generic page that leaves them searching again.

Use representative addresses to test the implemented mappings. Include important service pages, articles, products and downloads where applicable. Check that the destination itself loads and that the journey does not loop or pass through avoidable intermediate redirects. Record the result against the intended mapping so a mismatch is visible.

Do not create redirects merely because a site changed hosts. If the public URLs stay the same, the main task is to verify those addresses on the new environment. Redirect planning becomes necessary where addresses or structure actually change. Keep the redirect record with the launch documentation, including who maintains it after the project closes.

Check canonical, indexing and sitemap settings separately

Several settings influence search discovery, and they should not be treated as one switch. Review the canonical URL, page-level indexing instructions, robots rules and sitemap entries for the pages intended to remain public. Also confirm that temporary development settings have not been carried into production unintentionally.

Start with important pages and representative templates. A page can load normally for a visitor while declaring an unintended canonical address or indexing instruction. Conversely, adding a URL to a sitemap does not establish that a search engine has indexed it. Use the available inspection tools to distinguish the page’s technical settings from its actual indexing status.

Record the exact canonical addresses you intend to monitor after launch. Where Search Console access exists, inspect the relevant property and important URLs through that account. If private account access is unavailable, state that limitation and complete the public technical checks. Avoid calling a migration’s indexing review finished merely because the sitemap URL opens.

Give business email its own acceptance checklist

Determine whether business email uses the website host, a separate email provider or another arrangement. Identify the person responsible for mail records and mailbox configuration. If the project changes nameservers, review the records that need to remain available. A website-only transfer should not quietly become an unplanned email move.

Define practical email checks before cutover. For the agreed setup, confirm that messages can be sent and received and that website inquiries reach the intended destination. If mailbox content is being transferred, specify what data is included and how completeness will be reviewed. Account setup and preservation of historical messages are different acceptance tasks.

Avoid replacing working mail settings with guesses. Keep the existing configuration record and coordinate any change with the person or provider responsible for email. If a problem appears after the switch, the team needs to know what changed, when it changed and what the previous arrangement was. That record is more useful than repeatedly testing the same failed message.

Test forms from entry to receipt

A form test should follow the inquiry beyond the submit button. Use clearly labeled test information, send it through the agreed route and check where it arrives. Review field validation, the success message, the destination inbox or CRM and any notification sent to the visitor. A visible confirmation alone does not prove delivery.

Include different form types if the website has more than one. A contact form, a quote request and an appointment inquiry may use different settings or integrations. Test optional fields and required fields, and check whether the form remains usable on a phone. Confirm that spam protection does not make the genuine inquiry journey unnecessarily difficult.

Document the intended behavior of external contact choices too. A WhatsApp link opens a conversation; it does not prove that the visitor sent a message. A mail link opens an email application; it does not provide server-side delivery confirmation. Keep those click actions separate from verified form submissions when reviewing the site’s lead measurement.

Add a store-specific data check when WooCommerce is involved

An active store needs a plan for data that changes during the project. Orders, stock levels, customer records and submissions may continue changing after the first destination copy is created. Identify which environment remains authoritative and how the final transfer will account for those changes.

Agree whether the move requires a temporary transaction pause, a final synchronization step or another method appropriate to the setup. Record who can make that decision and what customers will experience during the window. The method should be assessed for the actual store rather than copied from a brochure-site checklist.

Review products, variations, cart behavior, shipping, taxes and payment integrations within the agreed scope. Use suitable test arrangements for transaction checks. If the project involves real payment testing, agree that separately so an ordinary migration review does not create unintended charges. Also consider refunds or order management if the business needs those workflows immediately after launch.

Check integrations that depend on the environment

Build a list of the services connected to the website. This can include booking systems, payment gateways, email delivery, CRM tools, analytics and other business applications. Identify whether their operation depends on a domain, callback address, licence or server setting that changes during the migration.

For each essential integration, record an owner and a representative test. If a form sends a lead into a CRM, check the resulting record rather than only the form’s success state. If an appointment system is embedded from another provider, verify that the booking experience still works on the destination page and at the required screen sizes.

Keep integration access and responsibility explicit. A developer may be able to place an embed without having authority to modify the external service’s account. When that service needs a configuration change, assign it to the correct owner. The migration checklist should reveal dependencies, not encourage changes outside the agreed access or scope.

Inspect images, downloads and mobile presentation

Review the website with the content customers actually use. Check that featured images, gallery images, downloadable files and embedded content point to working destinations. A page can appear complete while a brochure link or an older media address returns an error. Include those assets in the relevant page-level test record.

Use common phone, tablet and desktop widths to inspect important templates. Look for cropped text, oversized menus, fields that extend beyond the screen and buttons that are difficult to use. Check long headings and long email addresses as well as short sample content. A layout that works with a single short headline may fail on a real service page.

Images should have suitable dimensions and file sizes for their placement. Modern formats and responsive variants can help reduce unnecessary downloads, but compression should be reviewed visually. Preserve clarity where an image communicates useful detail. Check that image dimensions reserve space in the layout and that below-the-fold media does not delay the initial experience unnecessarily.

Keep tracking and consent behavior in the launch review

List the measurement tools already in use and which events matter to the business. A migration should preserve intended tracking without assuming that every script is needed or correctly configured. Identify who controls the analytics account and whether the destination website still uses the intended property or configuration.

Test successful inquiry tracking separately from button clicks. A visitor clicking Get a Quote is different from a form being delivered and different again from a qualified business inquiry. Use event names and definitions that preserve those distinctions. Avoid placing the visitor’s personal form details into general analytics parameters.

Review the website’s actual privacy and consent behavior when analytics or other third-party services are involved. Do not replace an existing setup merely to simplify the migration unless that change is within scope. Record the tools retained, the checks performed and any unresolved question that requires the business owner’s review before publication.

Use a go-or-no-go review before switching

Create a short decision record from the completed checks. List what passed, what remains unresolved and whether an unresolved issue affects launch. Identify the approver and the exact change they are approving. This allows the team to distinguish a reviewed launch from a transfer that happened to finish copying files.

Some defects can wait for a planned follow-up; others affect the website’s primary business function. Decide that distinction around the actual site. A cosmetic spacing issue and a failed quote form have different practical consequences. Assign an owner and next step for every item so “we will check later” does not hide an important dependency.

After the switch, repeat the key checks on the public environment. Preview and production can differ because of caches, domain settings, integrations or hosting behavior. The migration record should show both the destination review before cutover and the live verification afterward. Keep publication, technical verification and subsequent search measurement as separate completion states.

A practical handover record for the business owner

At handover, request the agreed scope, account ownership information, backup and recovery record, URL mapping if needed, completed test results and unresolved items. Include the cancellation decision for old services and the support period covered by the project. Store this information where the business can retrieve it independently.

Ask the provider to explain what you can safely edit and what needs technical review. If the site was rebuilt in WordPress or Elementor, confirm the intended content-editing workflow. If an integration remains with another provider, retain that provider’s responsibilities in the record. A migration is easier to maintain when the handover explains how the website now operates.

Finally, set a review based on the business’s needs and available data. Operational checks can happen immediately, while useful search-performance comparison may need more time. When a problem appears, use the inventory, test record and change log to investigate it. Those documents turn a long checklist into practical support for the website after the move.

Remote review for the target US markets

StartMyWeb’s current location strategy prioritizes New York and Maryland, followed by Alabama, California and Colorado. For a business in those markets, agree the client timezone, review responsibilities and cutover contact before scheduling the move. The website’s platform, integrations and changing data determine its technical plan. A location name does not establish a standard timeline or price. StartMyWeb delivers remotely from Bengaluru, India; meeting availability and support arrangements are confirmed in the project proposal.

Turn the checklist into an agreed scope

Your migration quote should name the move, included tasks, exclusions, approval steps and post-launch checks. If you need implementation help, request a scoped WordPress migration quote. For a host-specific walkthrough, see the WordPress new-host guide.