Migrate from Voopty Inc. to Microsoft Dynamics 365 Sales

Voopty Student records map to Microsoft Dynamics 365 Sales Contact. Each student gets a Contact record with FirstName, LastName, Email, Phone, and Address populated from the student profile. The Voopty student ID is preserved in a custom field voopty_student_id__c for reconciliation and cross-reference. Student contact information migrates directly; parents or guardians stored as separate Client records if they represent billable contacts.

Voopty Clients (parents or adult learners who book services directly) split into two migrations: adult clients with enrollment map to Contact records with the same treatment as Students; parent or guardian contacts who manage student billing map to Contact records linked to the student Contact via a custom lookup field parent_contact__c. Clients who represent organizations (e.g., school district accounts) map to Account records with Contact records beneath them.

Voopty Teacher and Staff accounts with role-based permissions map to Microsoft Dynamics 365 Sales User records. We extract staff profiles including name, email, and role assignment. Role mapping is directional: Voopty teacher roles map to Sales roles in Dynamics; administrative roles map to System Administrator or custom Dynamics security roles. Staff without a corresponding Dynamics 365 User are held in a reconciliation queue for the customer's admin to provision accounts before record migration.

Voopty Course definitions (group classes, individual lesson configurations) map to Microsoft Dynamics 365 Sales Product2 records or a custom Course__c object depending on whether the customer wants course data in the product catalog or as a separate education-specific object. Course name, description, duration, and pricing migrate as product fields or custom object fields. Individual lesson vs. group class distinction is preserved as a custom picklist field course_type__c.

Voopty student-course enrollment relationships map to a custom enrollment junction object (Enrollment__c) with lookups to the Contact (student) and Product2 (course), plus fields for enrollment date, status, and completion date. Alternatively, for organizations preferring a CRM-native structure, enrollments map to Opportunity records representing the student's subscription period, with OpportunityLineItems representing the enrolled courses. The customer selects the enrollment model during scoping.

Voopty static recurring class schedules map to Microsoft Dynamics 365 Sales Event records representing individual scheduled sessions. Each Event gets a StartDateTime, EndDateTime, Subject (course name), and Location. The teacher is linked via EventRelation pointing to the corresponding User. Dynamic scheduling configurations that represent open booking slots map to a custom Session__c object rather than Events, preserving availability logic that Dynamics Events do not natively support.

Voopty attendance tracking per session per student maps to a custom Attendance__c object with lookups to the Contact (student), the Event or Session record (the class), and the User (teacher). Attendance status values (present, absent, late) map to a custom picklist attendance_status__c. Large attendance histories (over 50,000 records) may require Bulk API 2.0 with parent-record resolution to avoid API timeouts.

Voopty subscription plans tied to students or clients map to Microsoft Dynamics 365 Sales Opportunity records representing the active subscription period, or to Contract records if the customer uses the Contract object for recurring billing management. Plan periods map to Opportunity CloseDate or Contract StartDate/EndDate. Pricing migrates to Opportunity Amount or OpportunityLineItems. Note that Voopty's active-client threshold (one lesson per month) is flagged as a custom field subscription_active_threshold__c rather than a native Dynamics field.

Voopty payment records from WayForPay, LiqPay, and Stripe integrations map to Microsoft Dynamics 365 Sales Invoice or Order records, or to a custom Payment__c object depending on whether the destination org uses the native billing objects. Transaction IDs from the payment providers migrate to custom fields payment_transaction_id__c and payment_provider__c. Amount, currency, and payment date migrate directly. Recurring payment configurations do not migrate as automation; they require rebuild in Dynamics payment or billing integrations.