Migrate from Voopty Inc. to Pipedrive

Voopty Student records map to Pipedrive People. We extract student first name, last name, email, phone, and address fields from the Voopty CSV export. If Voopty stores the student under a combined name field, we split on the first space and assign the remainder to the last_name field. The student_id from Voopty is preserved in a custom field voopty_student_id__c for referential integrity during reconciliation. If the Student has an associated Guardian record in Voopty, the Guardian maps as a second People record with a custom field guardian_of__c pointing to the student's voopty_student_id__c.

Voopty Client records (representing parents or adult learners who book directly) map to Pipedrive People. We treat Client as a parallel entity to Student during migration rather than merging them; this prevents accidental deduplication where a parent and child both exist as contacts. Active status is reclassified: Voopty defines an active client as one with at least one lesson per month, so we populate a custom field voopty_active_threshold__c with the literal string 'one lesson per month' and a numeric field voopty_lessons_last_30_days__c to preserve the original logic. Pipedrive's native active/inactive flag is set based on the Voopty status field, not the derived threshold.

Voopty Course records map to Pipedrive Organization, with the course name stored in the Organization name field and a custom field course_type__c containing the program classification (group class, individual lesson, workshop). Each migrated Student or Client record that is enrolled in a given Course receives a linked Organization relationship in Pipedrive. A single Voopty Course can enroll multiple students, so the Organization is created first and the student-course associations are established as Activity links in a second pass.

Voopty Staff accounts with role-based permissions map to Pipedrive User records. We extract staff name, email, and role (teacher or administrator). Voopty role assignments (which teachers have access to which courses, which administrators can manage billing) do not map directly to Pipedrive's permission model, so we preserve the original role in a custom field voopty_role__c on the User record. The customer's Pipedrive admin assigns the appropriate Pipedrive role (regular user, admin) after migration.

Voopty Scheduled Sessions map to Pipedrive Activity records. Static fixed recurring sessions are converted to Pipedrive Event records with recurrence preserved as a JSON structure in a custom field voopty_recurrence__c. Dynamic scheduling configurations are mapped field-by-field: session date maps to Activity date, duration maps to a custom field, and the associated Course and Teacher resolve to the linked Organization and User. Each Activity is linked to the enrolled People records via the Activity's Person association.

Voopty Attendance records track whether a student was present, absent, or late per session. Pipedrive Activities do not have a native attendance field, so we map attendance status to a custom picklist field attendance_status__c on the linked Task (values: present, absent, late, excused). The session reference maps to the parent Task via the Activity date and linked Organization (Course). Attendance timestamps migrate as a custom datetime field attendance_time__c.

Voopty Subscription plans tied to students or clients map to Pipedrive Deals. The subscription plan name becomes the Deal title, the billing amount becomes Deal value, and the subscription period start and end dates map to the Pipedrive close date (end of subscription period). The deal stage is set to Won for active subscriptions and Lost for expired ones, with a custom field subscription_status__c holding the original Voopty status for reporting. Note that Pipedrive Deals do not support recurring billing natively; ongoing subscription renewals require manual stage updates or workflow automation rebuilt by the customer's admin.

Voopty Payment records tied to WayForPay, LiqPay, and Stripe do not map to any native Pipedrive object. We store payment data in custom fields on the associated Person or Deal record: payment_amount__c (decimal), payment_date__c (date), payment_processor__c (picklist: WayForPay, LiqPay, Stripe, Other), payment_status__c (picklist: completed, pending, refunded), and payment_transaction_id__c (text). Multi-currency amounts are stored with the original currency code in payment_currency__c. If the customer requires financial reporting, we recommend a separate finance integration post-migration.

Voopty attendance records reference a specific scheduled session and a specific student. We resolve both lookups during migration: the student Voopty ID resolves to a Pipedrive People record (via voopty_student_id__c), and the session date plus course resolves to a Pipedrive Activity (via Activity date and Organization link). The attendance status is appended to the Activity as a custom field. This composite mapping ensures that a student's attendance history is queryable by course and date in Pipedrive without requiring a custom object.

Voopty tags applied to students (such as cohort labels, enrollment type, or behavioral tags) migrate as custom fields on the People record. Multi-value tags are stored as multi-select picklist fields. The customer chooses during scoping whether to create individual custom fields per tag category or a single tags__c text field with comma-separated values. We do not create Pipedrive Label records because they are used for deal categorization, not person-level attributes.