Switch from Kenko to Elara: what to export and what comes across
By Elara team · Published
Export two Kenko reports, customers and memberships, plus the recommended ones, all on the same day and for all locations and statuses. Elara reads them in the Migration Center, shows every problem it finds before anything is written, then imports customers, memberships with their credit balances, gift card balances, sessions, bookings and payment history. The exports never carry saved cards or recurring billing: members keep the access they already paid for, through the next billing date in Kenko, and then continue on an Elara plan, with a card they add or one the payment processors move (below).
The export table below is generated from the same catalogue the Migration Center uses, so it changes when the importer does; the rules, findings and steps are taken from the importer and its help page. Kenko is a trademark of its owner, and this guide is not affiliated with or endorsed by Kenko.
Which Kenko reports to export
Customers and memberships are required. Without the recommended reports a part of the studio stays behind. If subscriptions, payments or both booking report alternatives are missing, the analysis warns that a recommended report is absent. It raises no finding for missing gift cards or orders, so, after the first analysis, check that both are ticked under What to export from Kenko in the Migration Center before you import. Optional reports are recognized so a bundle containing them is understood rather than rejected.
| Report | Needed | Export | What Elara does with it | Columns Elara needs |
|---|---|---|---|---|
| Customers | Required | As of today, no date filter | Customer profiles: name, email, phone, date of birth, status and promotional email consent. | contact_email, contact_status, contact_first_name, contact_added_on |
| Memberships | Required | As of today, no date filter | Memberships on the Elara plans you map them to, with remaining credit balances and access dates. | contact_email, membership_name, membership_status, credits_balance |
| Subscriptions | Recommended | As of today, no date filter | Read and counted, not imported. Used to stop imported access at the next billing date Kenko already collected for. No recurring charge is created. | contact_email, subscription_plan_name, subscription_status, subscription_started_at, credits_balance |
| Payments | Recommended | All dates (a range leaves bookings or history outside it behind) | Payment history on each customer profile, marked as imported. Refund those payments in Kenko, not Elara. | payment_id, payment_amount, payment_status, payment_paid_at |
| Orders | Recommended | All dates (a range leaves bookings or history outside it behind) | Read and counted, not imported. | order_id, order_total, order_currency, order_status, order_created_at |
| Gift cards | Recommended | As of today, no date filter | Gift cards with their codes, original value, remaining balance and expiry. Recipient details are not copied. | gift_card_code, gift_card_initial_value, gift_card_balance, gift_card_currency, gift_card_status |
| Bookings | Recommended | All dates (a range leaves bookings or history outside it behind) | Past and upcoming bookings with status, linked to the customer and the matching exported session. Requires booking and event IDs. | booking_id, event_id, contact_email, booking_status, booking_starts_at |
| Sales by item | Optional | All dates (a range leaves bookings or history outside it behind) | Read and counted, not imported. | sale_item_name, sale_item_quantity, sale_item_gross, sale_item_currency |
| All bookings | Optional | All dates (a range leaves bookings or history outside it behind) | Past and upcoming reservations from All bookings, matched to the exported sessions by date, name and location. Ambiguous session matches require event IDs or local start times. | booking_activity_event_date, booking_activity_checkin_status, contact_email, booking_activity_booked_on, booking_activity_status, booking_activity_event_name, booking_activity_event_type, booking_activity_facility_name |
| Booking customer summary | Optional | All dates (a range leaves bookings or history outside it behind) | Read and counted, not imported. It holds totals per customer, not the bookings behind them. | contact_email, booking_summary_membership_status, booking_summary_last_event_date, booking_summary_total_bookings, booking_summary_total_visits, booking_summary_no_shows |
| Class events | Optional | All dates (a range leaves bookings or history outside it behind) | Sessions and their scheduled times, with capacity. Set prices and credit costs in Elara. | class_event_date, event_name, class_capacity, event_duration_minutes, event_location |
| Appointment events | Optional | All dates (a range leaves bookings or history outside it behind) | One-person sessions at their scheduled times. | event_id, appointment_service_name, event_starts_at, staff_name |
| Course events | Optional | All dates (a range leaves bookings or history outside it behind) | Read and counted, not imported. | event_id, course_name, course_session_count, event_starts_at |
| Cancellations | Optional | All dates (a range leaves bookings or history outside it behind) | Marks the matching imported bookings as cancelled. | booking_id, cancelled_at |
| No shows | Optional | All dates (a range leaves bookings or history outside it behind) | Marks the matching imported bookings as no-shows. | booking_id, no_show_marked_at |
| Staff | Optional | As of today, no date filter | Instructor records, matched to sessions by name. | staff_id, staff_name, staff_email, staff_status, staff_role |
| Locations | Optional | As of today, no date filter | Read and counted, not imported. You map each Kenko location to an Elara location instead. | location_id, location_name |
| Facilities | Optional | As of today, no date filter | Read and counted, not imported. | facility_id, facility_name |
| Services | Optional | As of today, no date filter | Read and counted, not imported. | service_id, service_name, service_price |
| Schedules | Optional | All dates (a range leaves bookings or history outside it behind) | Read and counted, not imported. Session times come from the class and appointment reports. | schedule_id, schedule_starts_at, schedule_ends_at |
| Waivers | Optional | All dates (a range leaves bookings or history outside it behind) | Read and counted, never imported. A signature on another system's document is not consent to yours, so members sign your Elara waiver. | waiver_id, contact_email, waiver_signed_at |
| Forms | Optional | All dates (a range leaves bookings or history outside it behind) | Read and counted, never imported. | form_id, contact_email, form_submitted_at |
Three export rules decide whether the import can start:
- Export everything as of the same moment. A membership or booking whose customer is missing from the customers export is left out. Take all the reports on one day, before anyone makes changes in Kenko.
- Don't filter by location or status. Elara cannot see a filter in the file, since a missing row leaves no trace, so you declare each report's filters in the Migration Center after uploading it. Each report counts as filtered until you tick All locations and All statuses for it. A declared location or status filter is a blocking finding, because members would be missing without anyone noticing. Re-export the report unfiltered rather than acknowledging the gap, and declare the filters truthfully.
- Don't put a date range on a current-state report. A date range on a report the table marks "As of today", such as customers, memberships, subscriptions or gift cards, drops records rather than old history, so it is a blocking finding too. A range on a history report is only a warning, but every row outside it stays behind, upcoming bookings included, so end the range on a bookings, class or appointment report after your last reserved session.
Column names don't have to match exactly. The Migration Center lists the header spellings it accepts for each column, and offers a blank template for every report Elara imports.
What happens to your data, step by step
- Describe the bundle. You name the Kenko account, the day the exports were taken, the time zone Kenko reported times in and the currency it billed in, and for each report whether you filtered it. You map each Kenko membership name to an Elara plan and each Kenko location to an Elara location. A membership on a plan you have not mapped is a blocking finding: map it, or acknowledge it and that membership is left out rather than attached to a guess. Elara starts reading about a minute after the last upload, and a bundle without a currency or export date shows as failed. Fill in the description as soon as the form appears; saving it sends the bundle to be read again.
- Analysis. Elara reads every file and lists findings. Some only inform you, such as late cancellations importing as plain cancellations because Elara does not record lateness. Others block, such as two customers sharing one email address: fix them in Kenko and export again, or acknowledge them. What acknowledging means depends on the finding: acknowledging a duplicate email leaves both customers out, with their memberships, bookings and payments, and acknowledging the subscriptions finding confirms you cancelled them in Kenko. Once nothing blocks, Elara reads the bundle again and shows the plan: how many customers, memberships, bookings and other records it will create. Nothing is written during analysis, so you can upload a rehearsal export, read the findings and cancel the run.
- Hold automations. Importing a year of history makes every record look new. While held, scheduled emails, reminders and membership expiries wait until you release, and the import will not start without it.
- Apply. Elara writes the reviewed plan. Once a run starts applying it can't be rolled back, so the rehearsal matters.
- Reconcile. Elara counts what landed and compares it with what the plan said would land. Any difference waits for you to accept or fix it before the run completes. First accept the records that did not land and re-run reconciliation. Then accept the source differences you have checked against Kenko, because a re-run clears those acceptances.
- Release the hold. Release the hold as soon as the run completes. Emails that were already overdue when you placed the hold are set aside; anything that came due during the hold goes out when you release.
One run takes up to 16 MB of files and 100,000 rows in total; a larger studio shortens the history reports or imports in more than one run. Uploaded files are kept for 30 days. A run not applied in that window has to be uploaded and analyzed again. The Migration Center help page covers each state in detail.
Upcoming bookings
Kenko's standard All bookings report and the ID-based Bookings report can both carry reservations for the upcoming weeks and later months, together with matching class or appointment exports. Upload one booking report, not both. The export cutoff is the snapshot date, not the last session date. Include every reserved future session in the event export, with its source ID and local start time, and use the correct source timezone.
All bookings rows match exported sessions by date, event name, event type and facility, with duration and instructor when provided. A date without a time is enough only when one session matches. If several sessions match, add the source event_id or local event_starts_at to identify the right one before importing; Elara never chooses a guessed session time. Missing session exports and ambiguous matches appear as findings with the source row numbers. A bookings-by-customer summary cannot transfer reservations.
Stop bookings and changes in Kenko before taking the final exports. Rehearse, hold automations, apply and reconcile, then compare the future roster with Kenko before switching booking links. Check dates, times, customers and statuses next week and months ahead. Imported classes start as drafts, and they are always new classes: the import never merges them with sessions you already created in Elara, so imported bookings sit on the imported copies. Review their prices, credit costs and capacity before publishing. If you already created the same session yourself, sell places on only one of the two, because they don't share a capacity. Importing a reservation does not charge money or spend the member's remaining credits again, and sends no booking confirmation. Imported classes arrive with no credit cost, so the first import does not tie an upcoming booking to the credit pack that paid for it. Once that run completes, set credit costs on the imported classes, which later runs leave alone, and start a new run with the same reports, including All bookings. That run links each upcoming booking nobody has changed since the import to the pack its All bookings row names, without spending another credit, so cancelling it returns the credit. A booking cancelled or changed before that run, or whose pack Elara could not identify or did not import, stays unlinked and returns no credit: staff add it back to the member's pack by hand. A member who cancels one online after you set the credit costs raises an item in Needs attention. The upcoming booking checklist covers the source requirements and cutover checks.
Memberships, credits and billing
The memberships export carries each member's plan, status and remaining credits. Elara imports the credit balance as it stands, so a year of booking history cannot spend a balance twice.
For recurring memberships, the subscriptions export decides how long imported access lasts. Elara does not continue the Kenko charge and does not create a new one.
- With the subscriptions report, a member's access runs through the earlier of the next billing date Kenko shows and the membership's own expiry, because that is the period they have already paid for. Before the import can go ahead you cancel the live subscriptions it lists in Kenko, then acknowledge the finding. Elara cannot see whether you did, so cancel them first.
- With no next billing date for a member in that report, Elara cannot tell how long their access should run, so the membership is a blocking finding: fix the export, or acknowledge it and that membership is left out.
- Without the report, the importer only warns and cannot tell which members are still billing. Recurring members keep access until their Kenko expiry date, which can be months past what they paid for, and a recurring membership with no expiry date fails when the run applies and shows up in reconciliation. Upload the report.
Don't cancel in Kenko and then export the subscriptions report again. A cancelled subscription next to an active membership reads as a conflict, and that member's membership is left out. Take the final exports first, then cancel the live subscriptions the findings list and acknowledge them.
What members do next depends on your processor. With Stripe live in Elara, a member whose imported membership has nothing billing it sees a Keep my membership button in their account during the last billing period before it ends. They pick a saved card or add one, and the first charge is dated the day after their paid-through date, so their access doesn't lapse. The button needs a monthly or yearly plan with a price above zero. Plans that add sales tax on top of the price, or that carry a minimum commitment, do not offer it, and a membership you map to a credit pack is not continued: those members buy again when it ends. With Square, a member buys the plan once the imported membership has ended, from their account or at the front desk. Plan the message to members around that date (below).
Cards on file
Saved cards stay with the payment processor that stored them, not in Kenko's reports, so no export can carry them. Kenko's help center describes connecting a Stripe account to Kenko,1 and on leaving it says the Stripe account "will be disconnected from Kenko" and asks studios to "cancel all subscriptions on Stripe".2 Ask Kenko which processor and which account hold your members' cards before you set a date, because that decides the route:
| Where the cards are today | What can happen |
|---|---|
| A Stripe account in your studio's name | Connect that same account to Elara, sweep it and link each member to their customer there, as below. |
| A Stripe account you can't connect directly | Stripe can copy customers and their saved payment methods from one Stripe account to another: the sending account shares, the receiving account accepts, and Stripe says most copies finish within 72 hours. Subscriptions, invoices and payment history are not copied.3 After the copy, link each member to their customer on the receiving account, as in the row above. |
| A processor other than Stripe | Card data moves between processors only through the processors themselves. Stripe imports it after a data migration request; Stripe warns that "Processors can take anywhere from a few days to several months to produce a final export", and that once it has valid data, "imports typically complete within 10 business days".4 |
When you connect the account Kenko billed through from Elara's payment settings, Elara watches it without charging anyone until you choose Go live. Sweep it from the Migration Center to list the customers, subscriptions and saved cards already on it, then link each member to their customer before they add a card in Elara, so the cards already saved become usable: a member who adds a card first gets a new customer record, and moving them back to their old customer means removing that link, which needs payments suspended in Elara once you have gone live. Once you sweep, any subscription the sweep finds still billing blocks Go live until it is linked to a member's membership or ended, and going live does not cancel or recreate it. The check sees only what the latest sweep found, so sweep again right before you go live. The Kenko subscriptions you cancel for the import are not billing, so those members continue their plan in Elara as described above.Can you move cards on file to new studio software?
Unless a transfer is confirmed in writing, plan for members to add a card in Elara themselves. Never collect card numbers by email or in a spreadsheet. Members add a card themselves in their Elara account or at checkout. The saved payment details guide explains the decisions in more depth.
What does not come across
- Signed waivers and forms. A signature on another studio's document is not consent to yours, so the importer reads them and never imports them. Members sign your Elara waiver before their next booking or check-in.
- Customer passwords. Imported customers sign in with an email link and can set a password afterwards.
- Courses, services and orders. Recognized and counted, not imported. Recreate courses as sessions and set prices in Elara.
- Scheduled cancellations. A membership set to cancel later in Kenko imports without that schedule. Cancel it in Elara after the import.
- Archived status, from some exports. A customers export that marks contacts only as customers or leads imports every customer as active, and the analysis says so. Customers Kenko marks inactive import as active from any export, because archiving hides a person from staff entirely. Archive former members in Elara afterwards.
- Join dates. An imported customer's profile shows the import day as the date they became a customer.
- Exact payment times, sometimes. Kenko's payments report can print afternoon times as morning ones. Elara settles the time from the same customer's booking in the All bookings report, or from the order of Kenko's payment IDs, so upload All bookings. When nothing settles it, the payment imports on the right day at the printed time, which may be 12 hours off, and the analysis lists those rows.
- Refunds of imported payments. Imported payments are history. Refund them in Kenko while you still have access, or in the payment account that took them, not in Elara.
A workable timeline
Elara does not promise a migration time; the size of your bundle and the findings decide it. This sequence keeps the old system available for checking until the end.
| When | What you do |
|---|---|
| Two weeks before | Create locations, plans and credit packs, your waiver and staff roles. Ask Kenko which processor and account hold your members' cards. Connect your payment provider from Elara's payment settings: an account connected there takes no payments until you choose Go live, which you do after cutover. |
| Ten days before | Export a rehearsal bundle, upload it, read every finding and cancel the run. Fix duplicates and missing emails in Kenko. |
| One week before | Tell members the date, what changes for them and that they will sign the new waiver. |
| Cutover day | Stop selling in Kenko. Export all reports and upload them. Review the findings, cancel the live subscriptions they list in Kenko without exporting again, and acknowledge. Hold automations, apply and reconcile. |
| Cutover day, after reconcile | Set credit costs on the imported classes, then start a new run with the same reports, including All bookings. Review its findings, apply under the hold and reconcile, so upcoming bookings link to the packs that paid for them. Spot-check ten members against Kenko: plan, credits, access end date, upcoming bookings. Release the hold. On the account Kenko billed through, sweep again, link members to their customers, go live and pay a test booking. Point your website's booking links at Elara. |
| Before each paid-through date | Remind members whose access is ending to continue their membership (Stripe) or buy their plan when it ends (Square). |
Cutover checklist
- Every Kenko membership name maps to an Elara plan of the same kind: credit balances to credit packs, unlimited access to a monthly, yearly or fixed-term plan.
- All reports exported on the same day, for all locations and all statuses.
- Rehearsal run analyzed and cancelled; blocking findings fixed at the source.
- Rehearsal checked against the difficult rows, not only clean active members: an archived member, a duplicate email, an expired pack with credits left, a cancelled membership with access remaining and a future booking paid with credits. Record what each should become before you look at the result.
- Duplicate customer emails merged in Kenko.
- Waiver created and active in Elara.
- Payment provider connected and a test booking paid (after the release, on the account Kenko billed through).
- Live Kenko subscriptions cancelled before acknowledging, so nobody is charged twice.
- On the account Kenko billed through, a sweep run right before Go live, with no subscription still billing.
- Automations held before apply.
- Reconciliation settled and the run completed.
- Credit costs set on the imported classes and the import run again with All bookings, so upcoming bookings paid from an imported pack return their credit when cancelled.
- Gift card balances checked against Kenko for the largest cards.
- Ten members spot-checked by someone at the front desk using their own staff role.
- Spot checks compare each member's balance and access end date with Kenko, not only totals. A matching credit total can hide one member who lost five credits and another who gained five.
- Automations released.
- Member message sent, with each member's paid-through date.
- Kenko exports kept somewhere private for reference.
A sample message (replace the date with yours): "From November 1 we book through our new system. Your membership is paid through your next billing date and carries over. Before then, open your account with the email we have on file, add a payment method and continue your membership. We will never ask for card details by email." That wording fits a Stripe studio; with Square, ask members to buy their plan once their paid-through date has passed.
Questions owners ask
Do I need to keep paying Kenko during the switch? Keep access until reconciliation is settled and you have checked your members, so you can compare records. The import itself only needs the exported files.
Will members get a flood of emails? Imported customers are not sent a welcome email, and imported bookings send no confirmation. Scheduled emails wait while automations are held, so release the hold as soon as the run completes (step 6).
What if Kenko adds a column or renames one? An added column is reported and ignored. A renamed column is fine if its new name is one of the accepted spellings. A file missing a required column is refused before anything is written, and the export checklist shows which columns are expected.
Can I import in more than one go? Yes. Runs are sequential, and a later run updates or links to what an earlier one imported instead of creating duplicates.
What happens to a member with two Kenko memberships? A credit pack imports alongside other memberships. A customer can hold only one active monthly or yearly plan in Elara, so a second one is not imported; it shows up in reconciliation for you to settle. Two live subscriptions for the same member and plan are a blocking finding: settle the duplicate billing in Kenko and export again.
How long does the switch take? Elara does not promise a time. The timeline above allows two weeks, most of it setup and a rehearsal; the import itself runs on cutover day.
Could a member be charged by both systems? Only if a Kenko subscription keeps running, in Kenko or on the Stripe account Kenko billed through. The import creates no charge in Elara. Cancel the live subscriptions the findings list, and sweep the Stripe account before you go live so any still billing shows up. If you connect a different account to Elara, check the Kenko Stripe account's subscriptions yourself and cancel any still active.
Try it with your own export
Ask for a quote. Once your account is set up, run the Kenko analysis on a rehearsal export and read the findings before you switch booking links. The memberships page shows the plans and credit packs your Kenko memberships map to, and Elara vs Mindbody compares Elara with Mindbody.