Migrate from Voopty Inc. to Twenty CRM

Voopty Student records map to Twenty Person records with custom fields added via Settings > Data Model before import. Required custom fields include student_id (external reference), enrolled_courses (multi-select or related Custom Object link), attendance_rate (calculated percentage), and enrollment_status (active/inactive/enrolled). Voopty contact details (email, phone, address) map directly to the standard Person fields. We set Person type = Person since Twenty does not support a separate Student object natively.

Voopty Client records (adult learners and parents who book services) map to Twenty Person records. Where a single Voopty Client account spans multiple Student records (parent-child relationships), we create Person records for each parent account and link them via a custom person_relationship__c field or topic tagging. Active-client status derived from Voopty's one-lesson-per-month threshold is preserved in a custom field original_active_status__c for future reconciliation.

Voopty Staff records with teacher and administrator roles map to Twenty WorkspaceMembers. Role assignments (teacher, admin) migrate as custom fields on the WorkspaceMember record. Voopty staff contact details map to the WorkspaceMember profile fields. We extract staff records before student records so that Teacher lookups on Scheduled Sessions and Attendance records are resolvable at migration time.

Voopty Course records (group classes and individual lesson configurations) map to a Twenty Custom Object named Course, created via the /metadata API before migration. Custom fields include course_type (group/individual), max_students (integer), duration_minutes (integer), and pricing_tier (text or picklist). Course definitions are migrated before Student enrollment records so that the lookup relationship resolves at import time.

Voopty's student-course relationship (which students are enrolled in which courses) does not map to a native Twenty object. We create a CourseEnrollment Custom Object with fields student_id (lookup to Person), course_id (lookup to Course), enrollment_date, and status. This is the highest-risk relationship in the migration because it requires both the Student and Course records to exist and resolved before the enrollment import. We sequence CourseEnrollment last among core records.

Voopty Scheduled Sessions (both static fixed schedules and dynamic scheduling) map to a Twenty Custom Object named ScheduledSession. Fields include session_date (date), start_time and end_time, teacher_id (lookup to WorkspaceMember), course_id (lookup to Course), and session_type (static/dynamic). Recurrence rules from dynamic schedules are preserved as a custom recurrence_json__c text field. We convert static schedules to individual session records at migration time.

Voopty attendance tracking per session per student maps to a Twenty Custom Object named AttendanceRecord. Fields include student_id (lookup to Person), session_id (lookup to ScheduledSession), attendance_status (present/absent/excused), and notes. Status values require value-mapping since Voopty's attendance vocabulary may differ from the destination's conventions. We flag any attendance records with missing session references for manual resolution.

Voopty Subscription plans tied to students or clients map to a Twenty Custom Object named Subscription. Fields include subscriber_id (lookup to Person), plan_name, billing_cycle (monthly/quarterly/annual), amount, currency, start_date, and status. Billing cycle and pricing are stored as text and numeric fields rather than a native billing object since Twenty lacks a built-in subscription management module. We flag any subscription records referencing inactive Voopty clients for status reconciliation.

Voopty payment records tied to WayForPay, LiqPay, and Stripe integrations map to a Twenty Custom Object named Payment. Fields include payment_id (original transaction reference), subscriber_id (lookup to Person), amount, currency, payment_date, payment_provider (WayForPay/LiqPay/Stripe/other), and status (paid/pending/refunded). Provider references and transaction IDs preserve as text for audit purposes. Payment records are migrated after Subscription records so that the subscription_id lookup resolves correctly.

Voopty notes and session-level observations stored as text records map to Twenty Note objects linked via ContentDocumentLink to the parent Person or Custom Object record. We preserve note body as rich text and set the note creation date from the original Voopty timestamp. Notes are migrated after all parent records are in place.