Implementation guide
Move booking systems without guessing or losing control.
A sound migration does not begin with an import. First define the data scope, owner of each decision, quality criteria and the point at which the customer booking link can safely change.
This guide describes a controlled process. It does not promise that every provider exports every field or that different data models map one-to-one.
1. Start with an inventory, not a CSV file
List where clients, services, staff, resources, future appointments, consents, notes and cancellation rules live today. Assign a business owner and one decision to every dataset: migrate, archive or omit.
Separate data needed for continuing service from history that can remain in a controlled archive. A smaller scope reduces errors, duplicates and unnecessary processing of personal data.
- clients and contact details with a basis for continued use
- services, variants, prices, duration and buffers
- staff, roles, working hours, leave and shared resources
- only future appointments needed after cutover
- booking, cancellation, reminder and consent rules
2. Define mapping and quality rules
Column names are not a contract. Define phone format, time zone, duplicate detection, required values and what happens when a service or team member is unknown.
A dry run should end with a report: rows read, rejected records, duplicates, missing relationships and a sample for manual review. One invalid record must not silently alter the rest of the import.
3. Run a rehearsal and a short parallel period
Configure services, staff and resources first. Then perform a dry-run import without publishing the new link. Sample clients and appointments, including buffers, processing breaks, leave and shared-equipment scenarios.
During the parallel period, name one system as the source of truth for new bookings. Do not let staff enter the same appointments independently in two systems without a reconciliation procedure.
4. Cut over only after explicit criteria pass
Cutover includes the website link, Google Business Profile, social channels, QR codes and reception instructions. Retain the source export, import report and change log, but do not turn a local file into a permanent data store.
The rollback plan must state how to return to the previous booking channel when a critical scenario fails. Rollback cannot depend on staff reconstructing appointments from memory.
Operational gate
Pre-cutover checklist
Have the named process owner accept every item.
- Source, valid, rejected and duplicate record counts are reconciled.
- Future appointments retain the correct service, person, time, price and resource.
- Team permissions were tested with accounts holding different roles.
- Booking, rescheduling, cancellation and reminder paths passed a rehearsal.
- The salon has a current export and understands the complete exit path.
- The new link, QR code and customer notice have an owner and publication time.
- A rollback threshold, decision owner and procedure are documented.
Auditability
Minimum migration evidence log
You do not need a heavy project system. You need repeatable evidence that reconstructs the decision.
| Evidence | Owner | Control point |
|---|---|---|
| Source export and checksum | Salon owner | Before rehearsal and cutover |
| Mapping, rejection and duplicate report | Migration lead | After every import |
| Verified sample of clients and appointments | Reception or manager | Before acceptance |
| Critical-path test list | Salon manager | Before link publication |
| GO or ROLLBACK decision | Process owner | At cutover |
Related Ariveno contracts
Verify the product functions and data rules used by this guide on the public pages below.
Rehearse before cutover
Configure and validate the mapping before publication.
Ariveno lets you prepare services, staff, resources and a preview before sharing the new booking channel with customers.