Website Migration for Service Businesses: Move Platforms Without Losing the Customer Journey

Overview

A service-business website migration is not just a website project.

It is a customer-journey migration.

A visitor may enter through a Google result, land on a service page, click a booking button, choose a time, become a client, receive a confirmation, pay, get a reminder and later return for another service.

If you move the pages but break one of those handoffs, the new site can look better while the business performs worse.

That is why a salon, studio, photographer, coach, home-service company or local professional should migrate more carefully than “copy the text, point the domain, done.”

This guide gives you a practical sequence for moving platforms while protecting the parts that already work.

What counts as a website migration?

A migration can mean several different things:

These changes do not carry the same risk.

A hosting change with identical URLs is different from a new domain plus a full redesign plus new booking software.

The more things you change at once, the more carefully you need to test.

• moving to a different website builder;
• changing CMS, such as WordPress to a managed platform;
• moving from Wix or Squarespace to another system;
• changing hosting while keeping URLs the same;
• changing the domain;
• redesigning and changing the URL structure;
• replacing a website plus separate booking/CRM tools with a more integrated platform.

The safest migration principle: change only what needs to change

If your domain is good, keep it.

If an important URL is clear and already performs well, keep it when practical.

If a service page converts, preserve the useful content and intent even if the design changes.

If a booking workflow works, reproduce its rules before you switch traffic.

A migration is not a contest to make every identifier new.

The best migration often has a new platform underneath and surprising continuity on the surface.

Start with an inventory, not a new template

Before building the destination site, document the current system.

Create five inventories.

Decide what each old URL will become

Every important old URL needs one of four outcomes:

Do not let URLs “just happen” during the redesign.

A redirect map should exist before the domain points to the new platform.

1. Unchanged: same domain and same path.
2. Moved: permanent redirect to the closest relevant new URL.
3. Merged: permanent redirect into a stronger page that genuinely replaces it.
4. Removed: intentional 404/410 when there is no useful replacement and the content should disappear.

Preserve URLs when they are already good

Suppose the old site has:

and those pages match the services people search for.

Keeping those paths may be safer than changing them to:

A new information architecture can be useful, but it should solve a real problem.

Do not change URLs only because the new platform generates a different default.

• /wedding-photography
• /family-photography
• /studio-rental
• /services/01-weddings
• /services/02-family
• /rentals/main-studio-space

Use permanent redirects for permanently moved pages

Google Search Central recommends permanent server-side redirects when a page has permanently moved. 301 and 308 are standard permanent redirect signals.

For a migration, this means:

old URL → closest relevant new URL

not:

every old URL → homepage

For example:

A redirect should preserve intent for the human visitor as well as for search engines.

Avoid long redirect chains

A migration sometimes inherits years of redirects.

Bad:

/old-service → /services-old → /services-new → /services

Better:

/old-service → /services

Where you control the redirect configuration, point historical URLs directly to the final destination.

This reduces unnecessary hops and makes troubleshooting easier.

Prepare a sitemap for the new public structure

A sitemap helps search engines discover the URLs you want crawled.

Google specifically notes that a sitemap can be helpful after a site move.

Your migration checklist should verify that the production sitemap:

Do not assume a sitemap is correct because the platform generated one automatically. Inspect it.

• is accessible;
• contains canonical public pages;
• uses final production URLs;
• does not contain staging URLs;
• does not include drafts or private pages;
• does not include pages you intentionally noindex;
• updates when publication changes.

Protect Search Console verification

Search Console is especially valuable during a migration because it can show crawling, indexing and performance changes.

Before launch:

After launch, inspect important URLs rather than waiting for a monthly report to tell you something is wrong.

• confirm you can still access the property;
• know which verification method is being used;
• preserve verification files/meta tags if your setup depends on them;
• verify a new property if the domain itself is changing;
• keep the old property available during the transition.

Expect some search fluctuation

A well-executed migration reduces risk. It does not guarantee that rankings will be frozen in place.

Search engines need to crawl and process the new setup.

If URLs or the domain change, temporary movement can happen while signals are transferred and the new pages are reprocessed.

The goal is not “zero movement under any circumstances.”

The goal is:

• preserve intent;
• send strong technical signals;
• avoid broken pages;
• maintain crawlability;
• monitor quickly;
• correct mistakes before they become persistent.

Do not let staging protection leak into production

During a rebuild, it is normal to block a staging site from indexing.

The dangerous moment is launch.

Before switching traffic, verify that the production site is not accidentally carrying:

One forgotten noindex can turn a design success into an SEO emergency.

• noindex from staging;
• a robots rule that blocks crawling;
• password protection;
• IP restrictions;
• canonicals pointing to a staging hostname;
• internal links pointing to preview URLs.

Migrate forms as business workflows

A contact form is not just fields on a page.

Document what happens after submission:

Recreating the same visual form without recreating the downstream workflow is not a complete migration.

1. Where is the enquiry stored?
2. Who is notified?
3. Is the client/contact created?
4. Does the customer receive confirmation?
5. Is spam filtered?
6. Is the source tracked?
7. Is consent text still appropriate?
8. Can staff find the enquiry later?

Migrate booking rules before booking pages

A booking page is only the visible layer of a scheduling system.

Before launch, recreate and verify:

Then test the booking page.

The booking page best practices guide helps with the visitor-facing layer, but the operational rules must be correct underneath it.

• service names;
• service durations;
• prices or quote rules;
• staff/resources;
• resource relationships;
• working hours;
• date exceptions;
• minimum notice;
• booking horizon;
• slot intervals;
• buffers;
• confirmation rules;
• cancellation/rescheduling rules;
• payment requirements;
• reminder timing;
• calendar sync.

Test double-booking scenarios

A migration is a good time to expose scheduling assumptions.

Test situations such as:

If the new platform cannot model the real business rule, discover that before the old system is cancelled.

• two clients request the same time;
• one staff member serves two services;
• a room is needed for several service types;
• Google Calendar already has a busy event;
• a service has buffer time;
• a staff member has a day off;
• an appointment is rescheduled;
• a booking is cancelled and the slot becomes available again.

Migrate client data carefully

Client data is more sensitive than page copy.

Before moving it, define:

Do not dump every historical field into the new CRM merely because it can be exported.

A cleaner client model is often one of the benefits of replatforming.

OneStudio's current CRM model connects client records to booking history and related activity. See OneStudio features for the current product scope.

• what data you need;
• what you are allowed to retain and transfer;
• which system is the legal/source record;
• how duplicates will be handled;
• whether historical bookings need to move or only active clients;
• what notes are operationally useful;
• whether consent records must be retained separately;
• how the export is secured and deleted after use.

Keep calendar ownership clear

If bookings synchronize with Google Calendar or another work calendar, determine whether the old booking tool creates events, reads busy time, or both.

During the transition, avoid a period where two systems both create the same event.

A safer approach is:

OneStudio currently supports a Google Calendar connection where new/changed bookings can be reflected in the work calendar and busy time can affect availability.

1. Document the current calendar connection.
2. Choose the migration cutover point.
3. Connect and test the new system.
4. Prevent duplicate event creation.
5. Verify busy-time behavior.
6. Retire the old integration only after the new one is stable.

Preserve tracking before you redesign dashboards

Do not wait until after launch to remember analytics.

At minimum, verify that you can compare:

The exact analytics stack can change, but you need a baseline.

If you cannot compare the old and new systems, you will not know whether the migration improved the business or only the design.

• traffic before and after migration;
• important landing pages;
• booking starts;
• booking completions;
• form submissions;
• calls/click-to-call if tracked;
• payment events if appropriate;
• cancellations or no-shows where the system records them;
• source/UTM information.

Keep Google Business Profile aligned

For a local service business, the website link in Google Business Profile is part of the migration.

After the new site is live:

Do not create a new Business Profile because the website platform changed.

For the broader local-search setup, see local SEO for service businesses.

• confirm the website link uses the final canonical domain;
• verify appointment/booking links if used;
• confirm business name/address/service-area information still matches the website;
• test important service pages from mobile;
• make sure the site presents the same services the profile promises.

Domain migration and platform migration are separate decisions

If the platform changes but the business identity does not, keeping the same domain often reduces unnecessary complexity.

Changing the domain can be justified when:

But “new website, therefore new domain” is not a rule.

If you do change the domain, the migration needs additional search-engine and brand-transition work.

• the business rebrands;
• the old domain is legally or commercially unusable;
• ownership problems require a change;
• the current domain is genuinely harmful or misleading.

DNS: prepare for the least glamorous launch task

DNS controls where the domain points.

Before launch:

Do not replace the whole DNS zone when you only need to change one website record unless you understand every record being removed.

A website launch should not break business email.

• confirm registrar access;
• export or screenshot existing DNS records;
• identify email records such as MX/SPF/DKIM/DMARC that must not be accidentally removed;
• know which records the new platform requires;
• understand whether www and apex/root domain will both work;
• confirm HTTPS/certificate behavior;
• plan rollback if the new site fails.

Test the new site before changing DNS

A pre-launch test should include more than clicking the homepage.

The launch-day sequence

A reliable sequence looks like this:

Do not schedule a migration for the busiest hour of your busiest day.

1. Freeze non-essential edits on the old site.
2. Take final exports/backups.
3. Confirm redirect configuration.
4. Confirm new site is production-ready.
5. Remove temporary crawl/index blocks from the production version.
6. Point the domain/DNS as planned.
7. Confirm HTTPS.
8. Test homepage and priority service URLs.
9. Test old URLs and redirects.
10. Submit a real booking or enquiry.
11. Confirm notification delivery.
12. Confirm calendar behavior.
13. Confirm analytics.
14. Inspect the sitemap.
15. Update external links you control when necessary, including the Business Profile website/booking link.
16. Keep the old platform available until validation is complete when your contract/setup allows it.

The first 48 hours after launch

Watch operational failures first.

Check:

A migration that loses bookings for two days is a business problem even if every SEO tag is perfect.

• can clients book?
• can staff see the bookings?
• are confirmations arriving?
• are payment states correct?
• are calendar conflicts controlled?
• do forms arrive?
• do important old URLs redirect correctly?
• are there 404 spikes?
• does the site work on mobile networks?

The first 30 days after launch

Build a simple migration scorecard.

Track weekly:

Do not judge the migration from one ranking screenshot.

The customer journey matters more than a single keyword position.

When not to migrate yet

Delay the migration if:

“Not yet” can be a good migration decision.

• nobody has registrar/DNS access;
• important client data cannot yet be exported safely;
• you do not know which URLs generate business;
• the new booking rules have not been tested;
• a seasonal peak makes operational risk unacceptable;
• a critical plugin/integration has no replacement;
• you cannot implement redirects for changed URLs;
• the new site is still carrying staging blocks;
• there is no rollback or recovery plan.

Example: moving from a website builder plus separate booking tool

A photography studio has:

The migration goal is not simply to reproduce the homepage in OneStudio.

The goal is to rebuild the system so:

That is an operational migration with a website component.

• a marketing site on one platform;
• booking on another;
• client notes in a spreadsheet;
• a work Google Calendar;
• payment tracking elsewhere.
• service pages lead to the correct booking path;
• booking rules match staff/space availability;
• clients and bookings are connected;
• Google Calendar is tested;
• payment status is visible where appropriate;
• reminders work;
• the same domain and important URLs continue to resolve.

Example: WordPress redesign with the same domain

A local professional has a WordPress site with good rankings but an outdated design. Booking is simple and content is strong.

A safer replatforming plan may keep:

Then change:

This reduces the number of search variables changed at once.

• the domain;
• service-page URLs;
• high-performing copy;
• page intent;
• existing external links.
• design;
• editor/platform;
• booking integration;
• CRM/client workflow;
• analytics implementation where needed.

How OneStudio fits into a migration decision

OneStudio is relevant when the desired destination is not merely a new page builder.

Its current product scope can connect:

That can reduce tool handoffs for a service business, but it does not guarantee that every feature from your old platform exists.

Before moving, create a must-have / nice-to-have / no-longer-needed list and verify every must-have item against the current features.

Then check current pricing for the modules and limits that apply to your intended setup.

• website editing and publication;
• custom domain/hosting/HTTPS foundation;
• services and booking;
• staff, rooms or equipment as resources;
• working hours and exceptions;
• Google Calendar;
• client/CRM records;
• payment status when enabled;
• confirmations/reminders when enabled;
• media/portfolio;
• business analytics.

A migration acceptance checklist

Do not call the project complete until these are true:

• Domain opens the new site over HTTPS.
• Mobile navigation works.
• Important service pages are present.
• Contact details are correct.
• Forms work.
• Legal pages are reachable.
• Priority old URLs are unchanged or redirect correctly.
• No accidental staging noindex remains.
• Canonicals use production URLs.
• Sitemap is accessible and clean.
• Search Console verification works.
• Important internal links point to final URLs.
• Services/prices/durations are correct.
• Working hours and exceptions are correct.
• Resources are assigned correctly.
• Test booking completes.
• Staff see the booking.
• Calendar behavior is correct.
• Confirmation/reminder behavior is correct.
• Required client data is migrated or safely archived.
• Duplicate handling is understood.
• Payment status behaves as expected when enabled.
• Analytics is receiving data.
• Booking/enquiry conversions can be measured.
• Pre-launch baseline has been saved.
• A 30-day review date is scheduled internally.

Final rule: migrate the business system, not just the pixels

The safest service-business migration protects four things at the same time:

If you are evaluating OneStudio as the destination, start by mapping your current workflow against the OneStudio features and the published website + CRM guide. Then prove the new booking and client workflow before changing DNS.

A successful migration is not the moment the new homepage goes live.

It is the moment customers can still find you, book you, hear from you and become repeat clients without noticing the machinery changed underneath them.

1. Discovery - search engines and customers can still find the right pages.
2. Conversion - forms and booking still work.
3. Operations - staff can manage the client after the conversion.
4. Continuity - domain, redirects, calendar, notifications and measurement survive the change.