Migration & Onboarding

Goal: Standardize the "Zero-Downtime Migration" and "Concierge Onboarding" pillars into actionable, repeatable procedures.

Zero-Downtime Migration Pipeline

The largest barrier for "Legacy Operators" switching away from Kuschick or Turista is the anxiety of losing historical bookings, customer lists, and upcoming reservations.

Data Mapping (The Translation Layer)

The migration relies on a deterministic ETL (Extract, Transform, Load) pipeline mapping legacy dumps to the Busflow PostgreSQL schemas.

IMPORTANT

The exact field-level mapping tables and format-specific extraction logic (Kuschick CSV/Access, Turista SQL) require dedicated design passes per legacy system. This document defines the strategy, not the concrete mappings.

Core mapping targets:

• Customers → PersonProfile: Extract PII, preserve legacy IDs.
• Tours → TourOffering & TourDeparture: Reconstruct where possible, flag incomplete data for manual review.
• Bookings & Invoices → Booking & Invoice / FinancialLedger: Import as historical actuals. Must not overlap with new payment flows.

Booking Integration Services

Legacy migration is not only a one-time ETL problem. During wedge deployments, external booking forms or partner websites may need to create bookings in a legacy ERP first, in Busflow later, or in both systems during transition.

The current working model is a generic Booking Intake Service with provider-specific connectors:

• Generic intake layer: Accept booking payloads from external forms, validate required booking semantics, normalize booker/passenger/trip/seat/ancillary data, provide idempotency, store audit/debug context, and return stable success/error responses.
• Legacy connector / sidecar: Translate the normalized booking request into a specific target system such as Kuschick. This layer owns SOAP/WSDL details, auth quirks, legacy field names, proprietary validation rules, status-code mapping, and retry behavior.
• Busflow connector: Submit the same normalized booking intent into Busflow's Commerce APIs once Busflow becomes the system of record.

Native Busflow booking forms and tour routes must not depend on legacy ERP availability or legacy data quality. Legacy connectors support migration, coexistence, and partner integrations; they are not the source of truth for Busflow-owned checkout and routing flows.

The Satzart Kuschick integration is the first concrete learning source for this pattern. Capture Kuschick-specific data constructs as facts, not noise: Reise/Termin structures, passenger fields, agency/customer identifiers, seat/blocking semantics, ancillaries, document requirements, errors, and update/cancellation behavior. These details will shape future migration and coexistence specs.

Execution Strategy ("The Flip")

• T-30 Days: Extract initial dump. Provision tenant. Run dry-run migration to surface data quality issues.
• T-7 Days: Finalize tenant setup (payment gateway keys, messaging templates).
• T-0 (Launch Night): Delta dump of recent changes. Pipeline executes delta import. Route traffic to new system.

---

Concierge Onboarding ("Do-It-For-You")

To overcome the "Patchwork Operator" friction where the software feels like too much work to set up, Busflow offers a hands-on activation service during the critical first weeks.

Core Principle

The operator should experience value from day one without needing to learn the system first. The Busflow team handles initial configuration using the operator's real data — not stock demos.

Rough Flow

1. Intake: Operator shares their best-selling tour itineraries (PDF/Word/email).
2. Configuration: Busflow team uses internal tooling (including the Data-Entry Agent) to set up initial tour templates, boarding point networks, and basic capacity rules.
3. Handover: The onboarding call uses the operator's own live data. They publish their first real tour during the session.

NOTE

Management must finalize the exact scope of the concierge service (number of tours configured, duration of hand-holding) alongside the pricing model.