How to Migrate a Service Business from Jimdo to OneStudio

Overview

Jimdo in 2026 is not merely a website builder.

Its current small-business product can combine AI-created websites, one-to-one, group and recurring bookings, Smart Forms, a customer database, an online shop, payments, invoices or payment links in supported markets, local visibility tools and an AI business assistant.

That breadth changes the migration question.

A Jimdo-to-OneStudio move should not begin with "How do I copy the pages?" It should begin with "Which business jobs does Jimdo perform today, and which of them should OneStudio own tomorrow?"

First decide whether the move fits your operating model

OneStudio is strongest when the business revolves around services and appointments:

website → enquiry or booking → schedule/resources → client record → payment status → reminder → repeat service

Its current public product supports a visual website editor, contact forms, service booking, staff and resources, client records, payment status where enabled, reminders and operational analytics. If Google Calendar is connected, OneStudio uses a separate work calendar created for the connected business; it does not read or change personal or other Google calendars in the account.

Review \OneStudio features\ and \OneStudio pricing\ before treating the migration as a replacement plan.

Step 1: classify the Jimdo functions you actually use

Create a system inventory with four columns: function, current Jimdo feature, destination, migration action.

Include the following.

Step 2: build an ownership map before rebuilding

For every function, choose one owner after launch.

A typical service-first map might look like this:

This step prevents a common migration failure: discovering after launch that an "extra" Jimdo feature was actually operationally essential.

Step 3: create a page and URL migration map

List each important Jimdo URL and assign one destination URL.

For each page, decide whether to:

Preserve important search intent, not only visual layout.

For a service page, that usually means carrying across:

• service name and audience;
• offer details;
• pricing guidance;
• trust signals;
• local context;
• primary call to action;
• useful FAQ content;
• the strongest title/H1 topic.

1. preserve the path;
2. rebuild at a new path;
3. merge into a stronger page;
4. intentionally retire it.

Step 4: rebuild content without cloning old weaknesses

Migration is a useful moment to simplify the site.

Prioritize pages that answer real buying questions:

Avoid recreating thin pages simply because the old builder made them easy to add.

• What do you do?
• Who is the service for?
• What happens during the service?
• How long does it take?
• What does it cost?
• Who delivers it?
• Where is it available?
• Should the visitor book or enquire?

Step 5: translate Jimdo bookings into OneStudio scheduling logic

The two products can overlap on basic appointments, but do not assume identical booking models.

For every bookable offering, map:

OneStudio's current booking system explicitly supports staff, rooms and equipment as resources. Its optional Google Calendar connection writes and manages OneStudio booking events in a separate OneStudio-created work calendar rather than reading personal-calendar busy time.

• service name;
• duration;
• price;
• staff;
• location;
• working hours;
• days off;
• room/equipment requirements;
• direct booking vs enquiry-first;
• cancellation rules;
• deposit requirement;
• reminder behavior.

Step 6: preserve future bookings

Export, record or otherwise reconcile all upcoming appointments before cutover.

Use a migration register that includes:

Then mark each appointment as:

Never let the customer become the reconciliation mechanism.

• client;
• appointment type;
• date/time;
• recurring-series context if relevant;
• payment/deposit status;
• cancellation terms;
• contact details;
• staff assignment;
• important notes.
• recreated in OneStudio;
• intentionally left in Jimdo until completion;
• cancelled/rebooked with customer confirmation;
• managed through a temporary controlled list.

Step 7: rebuild Smart Forms as intentional intake

Jimdo Smart Forms can collect tailored business enquiries and place contacts in the customer database.

When rebuilding:

OneStudio supports contact forms and enquiries, but do not claim an automatic Smart Forms importer or AI-generated equivalent unless that feature is explicitly available.

1. list every current question;
2. remove fields nobody uses;
3. separate simple contact from detailed qualification;
4. avoid collecting sensitive information without a clear purpose;
5. route each form to a real follow-up process.

Step 8: migrate customer records selectively

Not every Jimdo database contact belongs in OneStudio CRM.

Separate:

For service clients, prioritize useful continuity:

Test a small sample first. Do not assume field mappings or historical objects will import automatically.

• service clients;
• leads worth retaining;
• shop-only customers;
• newsletter contacts;
• old or duplicate records;
• test data.
• contact details;
• booking history that still matters;
• notes you lawfully need;
• tags/labels if your project uses them;
• payment status context where appropriate.

Step 9: protect shop, orders and financial records

If you use Jimdo ecommerce, treat it as its own migration project.

Before changing anything, retain the records you need for:

OneStudio currently supports payment status around service workflows where payments are enabled, but it is not positioned as a general ecommerce catalog, order-management or invoicing replacement.

If product sales remain important, keep a commerce system that supports them.

• open orders;
• completed orders;
• refunds;
• products and variants;
• customer access;
• taxes/accounting;
• invoices;
• payment history;
• legal retention.

Step 10: preserve local visibility separately

If Jimdo Local or brand-monitoring tools are part of your current workflow, document every connected profile before migration.

A website platform change should not accidentally create inconsistent business details across maps, directories and social profiles.

After launch, update the destination URL on the profiles you control, but do not assume OneStudio manages the listings themselves.

Step 11: protect domain, DNS and email

Before DNS changes:

Do not cancel the Jimdo plan or transfer the domain early just to "get started."

The replacement should be built and acceptance-tested before cutover.

• identify the registrar;
• record current DNS entries;
• identify web-hosting records;
• preserve MX records for email;
• preserve SPF, DKIM and DMARC;
• note verification records for third-party tools;
• confirm who has access to the domain account.

Step 12: run a real pre-launch test

Step 13: launch, monitor and only then retire Jimdo

For the first days after launch, watch:

Keep Jimdo available long enough to resolve missed dependencies and preserve records. Retirement comes after verification, not on launch morning.

• successful bookings;
• form submissions;
• payment/deposit status where used;
• reminder delivery;
• staff schedule conflicts;
• broken old links;
• traffic to important service pages;
• customer confusion about changed flows.

When a hybrid setup is the smarter move

A service business does not have to move every function at once.

For example, OneStudio could own the public service site, appointment workflow and client records while a separate commerce or accounting system continues to handle products and invoices.

That is often safer than forcing an all-in-one migration into a product that does not claim every source capability.

Migrate the operating system, not just the pixels

The safest order is:

inventory → ownership map → page/URL map → rebuild → booking/data migration → acceptance test → DNS cutover → monitor

If the business is genuinely service-first, use \OneStudio features\ and \OneStudio pricing\ to build the destination map before changing anything in Jimdo.

Questions businesses ask