Migration Center

The Migration Center imports a studio's existing customers, memberships, classes, bookings and payments from Kenko or Mindbody. Each import is a migration run: a bounded unit of work that reads a set of exported reports, stages a plan, applies it, and reconciles the result.

Gift cards and their remaining balances import from Kenko only. Elara's Mindbody import does not bring gift cards over. Once you stop selling and redeeming gift cards in Mindbody, issue a gift card in Elara for each outstanding balance. A custom code can be 4 to 32 letters, digits, or hyphens, so a Mindbody code in that shape can be kept. Issuing a card with a recipient email sends that recipient a gift card email right away.

Transfer upcoming bookings

Kenko's All bookings and ID-based bookings reports can import reservations for the coming weeks and later months, together with their matching session exports. The export cutoff describes when the snapshot was taken, not the last date a session can run. There is no separate future-booking date limit: only bookings and sessions present in the uploaded files can transfer.

Source	Upcoming bookings
Kenko ID-based bookings	Supported with matching class or appointment events and customer profiles.
Kenko standard All bookings	Supported with matching exported sessions. Date, event name, event type and facility must identify one session. Include event IDs or local start times when several sessions match.
Mindbody API snapshot	New captures include classes and bookings through one calendar year after cutover by default. A later booking horizon can be chosen during capture. Appointments and waitlists are not supported.
Other platforms	This build has no importer for other source systems.

For a Kenko transfer:

1. Export customers and memberships, plus the bookings and matching class or appointment events. Include every future session that has a reservation, including sessions months ahead. Upload either the ID-based bookings report or All bookings, with the session exports. ID-based bookings need booking_id, event_id, contact_email, booking_status and booking_starts_at. All bookings needs the customer email, booked-on time, event date, status, event name, type, facility and check-in status columns. Each reservation must match a customer and a session in the bundle.
2. Export the matching events with their source ID, local start time and location. Class events also need a name, capacity and end time. Appointment events need appointment_service_name, staff_name and appointment_duration_minutes. Map each source location to an Elara location and set the source timezone correctly. Courses are not imported.
3. Run a rehearsal analysis. Resolve missing customers, missing events, conflicting dates and statuses, and duplicate active bookings. All bookings dates without a time can match a unique session. If several sessions match, include event_id or event_starts_at in the export to identify the session; the importer never chooses a guessed time. Source row numbers identify what needs correcting. A bookings-by-customer summary cannot transfer reservations.
4. Take the final exports after stopping bookings and changes in the old system. Hold automations, apply and reconcile. Keep the old system available for comparison until the checks below pass.
5. Check customer, session time, date and status against the old system for bookings next week and months ahead. Imported classes start as draft: review their prices, credit costs and capacity before publishing them.

Confirmed bookings keep their seats; cancellations and no-shows keep their statuses. Importing a booking does not charge money, debit the imported credit balance again, or send a booking confirmation. A completed run is not proof that an unsupported report transferred its reservations, so compare the future roster with the source before releasing the automation hold.

For Mindbody, capture has separate financial and booking date ranges. Sales stop at cutover; classes and reservations continue through the booking horizon. The capture tool defaults to one calendar year after cutover. Use --bookings-through YYYY-MM-DD when reservations extend further ahead. The Migration Center reads the date range from the snapshot and fills it in for you. Older snapshots without a booking horizon still stop at cutover; capture again with the current tool to include upcoming reservations.

For unsupported source systems or incomplete exports, obtain the missing source data or recreate the affected reservations in Elara and check the roster before switching booking links.

The unit of work

A run is one export bundle from one source account (a source namespace). Its plan is built from the studio as it is at analysis time and from the source links left by earlier runs. Once applied, a run's rows cannot be rolled back: reconciliation and operator review are the way out, never undo.

A migration that needs more than one bounded import is done as sequential runs over the same source namespace, each started after the previous one completed. The links written by the first run are what let the next one plan updates and links instead of duplicates:

• A source record already imported is linked to the row it created, and updated only where the export carries something newer.
• A source record not seen before is created.
• A record that depends on one from an earlier run (a membership for a customer the first run imported) resolves through that run's link.

There is no long-lived run that stays open across several report families. That design was rejected because a run's plan and approval are pinned to one export bundle: a run that stayed open would either re-plan under the owner without a fresh approval, or keep a 30-day artifact clock running against uploads made weeks apart. Sequential completed runs keep every approval about exactly the files it was given.

When a next run is allowed

A brand has one open run at a time, enforced by the database. A next run can start only when the previous one is completed or cancelled:

• Draft, analyzing, needs review, ready, failed: cancel the run to start a different one.
• Applying, reconciling, reconciliation required: the cutover is unfinished and cannot be cancelled. Finish it (settle reconciliation) before starting the next run. Two owners pressing Start a migration at once get exactly one run.

A run that has started applying cannot be abandoned. If part of its plan does not land, those records appear under reconciliation for the owner to accept or fix; the rest of the plan is applied as reviewed.

Automation hold

Importing a year of history makes every record look new to the studio's automations. Hold automations before applying: emails queue instead of sending.

• Apply refuses to start until the brand is held.
• Release is refused while a run is applying, reconciling, or waiting on reconciliation. The card says so and withholds the button; the server enforces it in the database, so a release that races an apply is refused as well.
• Every apply batch re-checks the hold before writing. If the hold is missing mid-import, the run pauses with nothing written and resumes once the brand is held again.
• Releasing sets aside sends that were already overdue when the hold began, rather than delivering them late. Sends that came due during the hold go out when you release, and sends due later go out normally.

Retention and limits

• Uploaded export files are kept for 30 days. A run that is not applied within that window refuses to apply, because its approved plan no longer matches a stored file. Re-upload and re-analyze instead.
• Analysis and apply run in the background. Keep the page open to watch progress; no second action is needed while a run is applying or reconciling.
• Report families this build cannot read are listed on the export checklist and are not imported.