← OneStudio Guides

Websites

How to Migrate a Service Business from SITE123 to OneStudio

Move a service-business website from SITE123 to OneStudio without losing important pages, bookings, client data, SEO signals or specialist SITE123 tools.

Overview

Moving from SITE123 to OneStudio is not a matter of copying a homepage and changing the domain.

SITE123 currently includes much more than a page builder. Its Schedule Booking system supports services, staff, resources, pricing, availability, registration questions, reminders, cancellations, payments and client self-service. The wider platform also includes ecommerce, events, restaurants, email marketing, client-zone features, online courses and multilingual website tooling.

OneStudio has a different center of gravity. Its public product connects a website editor with service booking, staff and resource availability, client records, payment status where enabled, reminders and operational analytics.

A safe migration therefore starts by deciding what OneStudio should replace, what should remain elsewhere and what should be retired.

The migration goal: preserve the customer journey, not the old interface

A migration is successful when customers can still move through the important steps without confusion:

find the right service -> understand the offer -> enquire or book -> receive confirmation -> arrive at the right time -> remain connected to the client record

The new site does not need to reproduce every SITE123 screen. It does need to preserve the business logic customers depend on.

Before changing DNS or cancelling anything, write down the current journey from first visit to completed appointment.

Step 1: inventory everything SITE123 currently does

Create a simple inventory before rebuilding anything.

Public website pages

Record every page that still matters, including:

For each page, capture the current URL, page title, main heading and business purpose. High-intent service pages are easy to forget when a redesign begins with the homepage.

  • homepage;
  • service pages;
  • pricing pages;
  • about and team pages;
  • locations;
  • contact pages;
  • FAQ pages;
  • portfolio or gallery pages;
  • blog or resource content;
  • legal pages;
  • campaign landing pages.

Booking configuration

SITE123's current Schedule Booking system can include services, service categories, staff, resources, price, availability, custom registration information, reminders, cancellation/rescheduling controls and client-zone behavior.

Record what the business actually uses:

This turns a vague migration into a configuration map.

  • service name and category;
  • description;
  • duration and price;
  • private, group, class or program format;
  • capacity where relevant;
  • assigned staff;
  • rooms/equipment or other resources;
  • service location;
  • availability rules;
  • booking questions;
  • cancellation/rescheduling settings;
  • reminder behavior;
  • client-zone actions customers rely on.

Forms and enquiries

List every contact or custom form and the information it collects. Retain form submissions the business is entitled and needs to keep.

Specialist SITE123 modules

Mark any current use of:

OneStudio should not be assumed to replace those functions automatically. If a specialist module matters to revenue or customer access, decide its destination before moving the website.

  • ecommerce;
  • restaurant tools;
  • events or ticketing;
  • online courses;
  • multilingual website tooling;
  • email marketing;
  • mailboxes;
  • forums;
  • donations;
  • client-zone/member features.

Step 2: decide what OneStudio will own

For a typical service business, OneStudio may become the home for:

Review OneStudio features and OneStudio pricing before mapping the old system.

  • public website pages;
  • contact forms and enquiries;
  • service catalog and pricing;
  • working hours;
  • staff, rooms or equipment used in booking;
  • website booking;
  • client records and booking history;
  • payment status where payments are enabled;
  • reminders and notifications where enabled;
  • operational booking analytics.

Do not force a feature-for-feature replacement

If the SITE123 setup depends on ecommerce, restaurant reservations, events, multilingual publishing, platform mailboxes or online courses, a hybrid stack or another destination may be necessary.

A migration can still make sense if OneStudio becomes the service-business operating layer while another tool continues to own a specialist function.

Step 3: build a URL and SEO preservation map

For every important SITE123 page, choose one outcome:

Preserve strong signals where practical:

A redesign does not require changing every URL. Stability is often safer for pages that already receive search traffic or links.

  • useful URL paths;
  • page topic;
  • SEO title intent;
  • main heading;
  • important copy;
  • image alt context;
  • internal relationships between service pages;
  • local business information.
  1. Keep the same URL path.
  2. Move the content to a new URL and redirect the old URL.
  3. Merge it into a stronger replacement page.
  4. Retire it because it no longer has value.

Make a redirect list before launch

If a URL changes, add it to a redirect worksheet before the new site goes live.

Do not assume OneStudio has a project-level redirect manager unless that behavior is confirmed for the exact environment. If redirect implementation is unresolved, treat it as a launch blocker rather than improvising after cutover.

Step 4: rebuild the public website first

Recreate the content customers need to make a decision.

For most service businesses, the first version should include:

Use the migration to remove thin, duplicated or obsolete pages rather than importing every historical fragment.

  • clear homepage positioning;
  • focused service pages;
  • pricing or pricing guidance where appropriate;
  • trust proof;
  • team information where staff matter;
  • location or service-area information;
  • enquiry and booking calls to action;
  • required legal pages.

Keep customer language, not builder language

A service page should answer:

The destination site should be clearer than the source, not merely newer.

  • What is this service?
  • Who is it for?
  • What does it cost or how is it priced?
  • How long does it take?
  • What should the customer prepare?
  • Can the customer book now, or should they enquire first?

Step 5: rebuild booking as business logic

Do not copy only service names. Recreate the rules that produce valid availability.

Map each service

Verify:

OneStudio can use staff, rooms and equipment as scheduling resources where the project uses those options. That matters when the real question is not only "Is 2:00 PM free?" but "Is the right person and resource combination free?"

  • duration;
  • price;
  • staff eligibility;
  • required room or equipment;
  • working hours;
  • days off and exceptions;
  • whether direct booking is appropriate;
  • whether an enquiry-first path is safer.

Treat group capacity carefully

SITE123 supports group and class-style booking modes. Do not assume every capacity rule maps one-to-one to OneStudio.

If group capacity is business-critical, verify the exact OneStudio behavior before sending public traffic. Keep the booking elsewhere or use an enquiry-first workflow if the required model is not supported.

Rebuild intake questions deliberately

SITE123 can collect custom registration details during booking. Classify each question as necessary before booking, useful later, sensitive and better collected elsewhere, or no longer needed.

Do not recreate old forms automatically just because they exist.

Step 6: preserve future bookings before changing systems

Create a verified list of every future appointment.

Keep the operational data staff actually needs:

Then decide whether each appointment will be recreated in OneStudio, completed in SITE123 or tracked temporarily in a controlled migration list.

The customer should never have to solve the software migration for the business.

  • client name and contact details;
  • service;
  • date and time;
  • assigned staff/resource;
  • location;
  • payment status if relevant;
  • important notes;
  • cancellation/reschedule context.

Step 7: move client information conservatively

OneStudio's CRM is designed around client continuity: contact details, related bookings, notes, tags and history.

That does not mean every SITE123 contact should become a OneStudio client record.

Before moving data:

Do not promise an automatic SITE123-to-OneStudio importer unless one is explicitly verified later.

  1. Remove obvious test records and junk.
  2. Separate newsletter subscribers from service clients where they serve different purposes.
  3. Decide which notes are still useful.
  4. Retain only data the business needs and is permitted to keep.
  5. Map source fields to destination fields.
  6. Test a small sample before moving a larger set.

Step 8: handle payments, ecommerce and subscriptions separately

OneStudio can keep payment status connected to a booking/client where payments are enabled. The current Business plan also lists online payments/deposits.

That is not the same as a general ecommerce migration.

If SITE123 handles product sales, event tickets, restaurant transactions, subscriptions or another specialist transaction, document that workflow separately.

Ask:

If the last answer is no, keep an appropriate system for that function.

  • Must old transaction history remain accessible?
  • Must customers continue to manage orders or purchases?
  • Does a verified replacement workflow exist in OneStudio today?

Step 9: protect domain and email before DNS changes

A domain cutover can affect more than the website.

Record the current DNS configuration and identify records used for:

Do not delete MX, SPF, DKIM, DMARC or other mail-related records merely because the website is moving.

Build and test the replacement site first. DNS should be one of the last steps.

  • website hosting;
  • email delivery;
  • email verification;
  • subdomains;
  • third-party services;
  • analytics or verification tools.

Step 10: run an acceptance test before launch

Test desktop and mobile.

Website test

Check navigation, service pages, forms, images, legal pages, important URLs, titles/headings, contact details and calls to action.

Booking test

Book realistic scenarios across services, staff, resource conflicts, working-hour boundaries, days off, mobile and admin-created bookings. Verify confirmation/reminder and payment/deposit behavior where enabled.

If Google Calendar is connected, test only the documented OneStudio model: bookings should create/update the expected events in the separate OneStudio-created work calendar. OneStudio's current Privacy Policy says it does not read or change the user's personal calendar or other Google calendars, so do not use personal-calendar busy-time blocking as a migration acceptance criterion.

Migration test

Confirm that future bookings are accounted for, required client data is available, old URLs have planned outcomes, email DNS is protected and specialist SITE123 features have a replacement or deliberate retirement plan.

Step 11: cut over, then monitor the first week

After the new site becomes public, watch the signals that reveal migration errors fastest:

Keep the old SITE123 account available long enough to verify data and resolve missed dependencies. Cancel only when the migration is genuinely complete.

  • enquiries received;
  • successful bookings;
  • failed or confusing booking attempts;
  • reminder delivery;
  • payment status where used;
  • broken URLs;
  • search visibility on important pages;
  • customer questions caused by changed workflows.

When not to migrate yet

Delay the switch if:

A delayed migration is cheaper than a broken customer journey.

  • replacement booking rules have not been tested;
  • future appointments are not reconciled;
  • domain or email ownership is unclear;
  • critical ecommerce, event, restaurant, course or multilingual functionality has no replacement;
  • redirect handling is not confirmed;
  • required client data has not been preserved;
  • staff have not tested the new admin workflow.

Build the replacement before you retire the source

The safest sequence is simple:

inventory -> map -> rebuild -> test -> cut over -> monitor -> retire

If the business is primarily service-led and you want the website, booking, resources and client history to live in one operating flow, review OneStudio features and OneStudio pricing before starting the migration map.

Questions businesses ask

Can OneStudio automatically import a SITE123 website?

Do not assume that. Plan the move as a controlled rebuild and data-mapping project unless a current importer is explicitly verified.

Does SITE123 already have booking?

Yes. SITE123 currently offers Schedule Booking with services, staff, resources, availability, registration fields, reminders, cancellations/rescheduling and payment options. The reason to migrate should be overall operational fit, not the mistaken idea that SITE123 lacks booking.

Should I move my domain before rebuilding the new site?

No. Build and test the replacement first, then plan DNS cutover after website, booking, email and URL checks pass.

Can I move ecommerce from SITE123 to OneStudio?

OneStudio is not positioned as a general ecommerce replacement. If ecommerce matters, keep or choose a system that supports the required catalog, cart, order and fulfillment workflow.