FREN
Guided migration

Change platform,
without losing the thread.

Prepare to migrate the members, credits and bookings needed for daily operations. What can be retained depends on the available exports; your team approves the checks before go-live.

See the steps Prepare a bsport migration
Structured support within the agreed scope

What you prepare. What we verify.

Prepare: authorised exports from your current software, booking and cancellation rules, offers, and a person responsible for validating the studio’s journeys.

Check together: data to retain, balances, future bookings and migration discrepancies. Test imports remain separate from live operations; the changeover date is chosen after the checks.

Depending on the available data

A defined scope before starting.

Data generally reviewed

  • Priority items — members, coaches, activities, rooms, capacities, passes, credits and future bookings.
  • To be confirmed — subscriptions, waitlists, consent records, accounts and portable payment identifiers only where the provider and compliance requirements allow; no raw card data is migrated.
  • Depending on the history — attendance, cancellations, no-shows, refunds, receipts and communications.

Missing history is never reconstructed artificially.

Without sufficient history, planned retention analysis, forecasts and certain simulations must display “Insufficient data”.

Checks, step by step

Prepare, test,
then decide.

Each phase produces the checks needed before starting the next.

I
Steps 01–03

Prepare

Understand sources, their quality and the rules to preserve before any transformation.

  1. 01
    Inventory

    We identify sources, formats, volumes, critical flows and rules to preserve.

    Source inventory and business priorities
  2. 02
    Analyse

    Available exports are checked before defining what can actually be migrated.

    Quality and feasibility report
  3. 03
    Define mappings

    Each field and rule is mapped to the GE2studio model, with documented decisions.

    Field mapping and transformation rules
II
Steps 04–06

Rehearse

Import into a test environment, reconcile and replay the full sequence.

  1. 04
    Import in a controlled environment

    Migration is performed in a dedicated environment, without affecting live operations.

    Validation dataset and rejection log
  2. 05
    Reconcile

    Volumes, credits, future bookings and expected balances are compared with the sources.

    Reconciliation report by data type
  3. 06
    Rehearse the cutover

    The full sequence is replayed to measure its duration and resolve discrepancies.

    Rehearsed timeline and resolved-discrepancy list
III
Steps 07–08

Cut over

Make a documented decision, retain a rollback option and support the launch.

  1. 07
    Decide on the cutover

    Your team confirms the go-live criteria and rollback procedures.

    Decision record and rollback plan
  2. 08
    Support the launch

    Enhanced support follows go-live according to the agreed scope.

    Follow-up plan, responsibilities and exit criteria

Your team stays in control. No sensitive import is considered complete without verification.

Reversibility

Rollback is not a magic button.

Code, the business database and payment operations follow separate procedures. A real transaction is never “rewound” through a simple technical restore.

Separate data sets

Validation imports can be replayed without duplicates, remain isolated from production and trigger no real payments, messages or automation.

Reconciliation criteria

Each data type has its own acceptance check; each rejected or transformed value retains its provenance.

Cutover decision

The go-live decision, its criteria and the people responsible are documented.

Your project, your pace

Let’s prepare your transition scenario.

Describe your current software and the journeys to preserve. This discussion defines the scope; it does not confirm a complete migration or a go-live date.

Discuss my migration Moving on from bsport?