Migrate from Voopty Inc. to Odoo CRM

Voopty Student records map to Odoo res.partner with a Partner Type set to Individual. The student's name, email, and phone migrate directly. Course enrollments and attendance history are preserved as Notes attached to the Partner record or as custom fields in a dedicated education extension module the customer's admin installs post-migration. The Voopty active-client threshold (one lesson per month) does not transfer; the customer's Odoo admin sets activity flags based on CRM engagement patterns.

Voopty Client records (parents, guardians, or adult learners who book services) map to Odoo res.partner. Adult learners who also enroll as students receive separate Partner records; parents or guardians are created as Individual Partners and linked to their associated Student Partners via the Odoo Contact multiselection field or a custom related field. Client-active status flag migrates as a boolean custom field partner_is_active_client__c since Odoo has no native activity-threshold concept.

Voopty Staff accounts map to Odoo res.users so that the original teachers and administrators can log in to Odoo post-migration. Voopty role-based permissions (teacher vs administrator) translate to Odoo group membership (Sales / Administrator / HR / Project User). The customer's Odoo admin provisions the res.users records before migration and we match by email address. Inactive Voopty staff map to Portal users in Odoo if the customer wants read-only access for external teachers.

Voopty Course records map to Odoo product.product with the product type set to Service. Course name becomes the product name; course description migrates to the product description field. Group class vs individual lesson configurations become product attributes or are mapped to separate product variants. If the customer uses Odoo Subscription, the course maps to a subscription template product that recurs on the student's subscription record.

Voopty static fixed schedules and dynamic scheduling configurations map to Odoo calendar.event records with recurrence rules preserved where Odoo's recurrence model supports them. Each session generates a calendar.event linked to the instructor's res.users calendar and to the course's product.product. Student attendance is tracked by linking calendar.event to the relevant res.partner records (student Partners). Dynamic scheduling rules that exceed Odoo calendar recurrence capabilities are documented as custom Odoo Studio configurations for the customer's admin to finalize.

Voopty attendance records per session per student have no native Odoo CRM equivalent. We migrate attendance as Notes attached to the calendar.event (session) record, containing the student name, attendance status (present, absent, late), and timestamp. Alternatively, if the customer installs the Odoo Education module from the Odoo App Store, attendance records map to the education.attendance model. We flag this choice during scoping.

Voopty Subscription plans tied to students or clients map to Odoo sale.order records (for one-time or fixed-term billing) or sale.subscription records (for recurring billing if the customer activates the Subscription app). Subscription period, pricing, and student enrollment are mapped to order lines referencing the course product. The active-client threshold from Voopty does not transfer; subscription status in Odoo reflects the customer's own billing logic.

Voopty payment records from WayForPay, LiqPay, and Stripe integrations map to Odoo account.move entries in the account module. Transaction IDs from the payment provider migrate to the account.payment.ref field. Payment amounts and dates transfer directly; the customer identifies which Odoo payment journal corresponds to each Voopty payment processor during scoping. We do not re-process payments; we record historical payment data as reconciled invoices or posted payments in Odoo accounting.

Voopty Telegram and email campaign configurations do not migrate as code. We extract the campaign names, contact segments, and message content into a written inventory document that the customer's admin uses to rebuild campaigns in Odoo Email Marketing or a third-party email tool of their choice. Campaign contact lists (Voopty students and clients) are already present in Odoo res.partner and can be re-segmented using Odoo's contact filters.

Voopty static scheduling exports require format conversion before Odoo import. We extract the recurring session definition (day of week, start time, end time, instructor, course) and map it to Odoo calendar.recurrence with the rrule fields populated per iCal RFC 5545. The recurrence links to the course product and instructor user so that Odoo generates calendar.event instances automatically. Any Voopty static schedule without a clear recurrence pattern is handled as individual calendar.event records.

Payment provider references (WayForPay transaction IDs, LiqPay payment IDs) do not map to standard Odoo fields because neither processor has a native Odoo module in the standard install. We store the provider name and transaction ID in a custom field payment_provider_ref__c on account.payment records, and the customer can install a third-party Odoo payment module (available on the Odoo App Store) post-migration if they want automatic reconciliation.

Voopty custom properties on Students, Clients, or Courses that have no Odoo standard field equivalent are pre-created as custom fields on the corresponding Odoo model (res.partner, product.product) before migration. We create the custom field schema via Odoo's Settings > Technical > Custom Fields interface or via a data migration script. All values transfer as their appropriate Odoo field type (char, text, integer, selection, many2one).