Migrate from Ziggu to Odoo CRM

Ziggu projects map to two Odoo objects depending on use case: active development projects with milestone tracking become project.project records with a custom Development_Phase__c stage field, while projects in the sales funnel (reservations, pre-seles) map to crm.lead opportunities so they flow through Odoo's pipeline stages. FlitStack AI applies a configurable rule — typically: if Ziggu project stage is 'Sales' or 'Reservation', route to crm.lead; if stage is 'Under Construction' or 'Handover', route to project.project — before migration runs.

Ziggu client records (name, email, phone, company, address) map directly to Odoo res.partner. Ziggu's portal-access flag becomes a custom field x_portal_access__c boolean. Ziggu's client rating or NPS score migrates as x_client_nps_score__c on the partner record. The res.partner record type (contact vs. company) is inferred from whether Ziggu stores a company name — if company name is present, the partner is created as type 'company'; otherwise as type 'contact' with a blank company partner link.

Ziggu units (apartment, lot, floor) are a hybrid: they carry a product identity (unit number, floor, area, price) and a project-task identity (selection milestones, approval status). We map the product identity to product.template with a x_unit_reference__c field storing the Ziggu unit ID, and we map the task identity to project.task records under the corresponding project.project. The Odoo product.product variant model handles unit-level pricing if Ziggu stores unit-specific prices.

Ziggu tasks linked to a project map directly to Odoo project.task under the corresponding project.project record. Task status (Not Started, In Progress, Blocked, Done) maps to Odoo's stage_id. Task priority maps to Odoo's priority field (0–3). The Ziggu task description, which may contain conversation history, is stored in project.task description as plain text. Owner resolution runs against Ziggu owner email matching Odoo res.users email.

All Ziggu file attachments (floor plans, selection catalogs, contracts, invoices) are downloaded from Ziggu's storage and re-uploaded to Odoo as ir.attachment records. Each ir.attachment is linked to the correct Odoo model and res_id — project documents link to project.project, unit documents link to product.template, client documents link to res.partner. Odoo's default file size limit is 25MB per attachment; files exceeding this are flagged for chunked upload or alternative storage.

Ziggu conversation threads are stored as mail.message records linked to the res.partner (client) record. Each message stores the original sender, timestamp, body text, and an x_ziggu_thread_id__c custom field for traceability. Attachment references within conversation messages are updated to point to the re-hosted ir.attachment records. Mail aliases (if configured) are mapped to Odoo's incoming mail server configuration.

Ziggu's approval chain (client selections — flooring type, fixture brand, color scheme — with stage gates and approver sign-offs) maps to a combination of project.task stages and a x_selection_status__c custom field on the task. The approver identity (which Ziggu records as a contact) is stored as a many2one to res.partner on the Odoo task. Approval timestamps are preserved in x_approval_timestamp__c. Odoo does not have a native approval workflow engine in its free CRM — this must be rebuilt in Odoo Studio or via the approval module on Odoo Apps.

Ziggu project-level custom properties (development type, zoning classification, target handover date, etc.) are migrated as Odoo custom fields on the project.project model. Odoo Community requires manual field creation via ir.model.fields; Odoo Enterprise supports Studio. We create fields with the x_ prefix, matching Ziggu's data type (char, selection, date, float) and preserving the pick-list values as Odoo selection options. Each custom field creation is logged in the migration plan for admin verification.

Ziggu client-level custom properties (client type, preferred contact method, referral source, investment profile) map to Odoo custom fields on res.partner. We create fields matching the Ziggu property type and selection options. Partner tags (Ziggu's grouping mechanism) map to Odoo res.partner.category records — existing tags are matched by name; new ones are created. Tag assignment is applied via res.partner.category_rel.

Ziggu automations — stage-change triggers, email notifications on approval completion, SLA timers on task escalation, and client-portal access provisioning rules — have no native Odoo CRM equivalent. We export the full workflow definitions (trigger conditions, actions, recipients) as a structured JSON spec that Odoo admins can use to rebuild in Odoo Studio (freeform automations), Odoo's base_action_rule module, or the OCA/server-tools module. This export is delivered as part of the migration plan, not as a runnable migration artifact.

Ziggu reports (project status reports, client NPS over time, unit selection completion rates) do not migrate. Odoo's reporting layer uses a different data model (crm.lead instead of project records). We migrate the underlying data so reports can be rebuilt in Odoo — project.task records are accessible via Odoo's project reporting views — but the report layouts and scheduled delivery configurations require manual rebuild in Odoo Studio or via custom SQL views connected to Odoo's spreadsheet reporting module.

If Ziggu's Financials add-on is in use, invoice and payment records migrate to Odoo account.move (invoices) and account.payment records. Ziggu invoice line items (unit, description, amount) map to Odoo invoice lines with the product.template reference preserved in the account.move.line. Payment records link to the invoice via reconcile fields. Odoo's chart of accounts structure is applied — accounts are created or mapped per Odoo's default chart-of-accounts template if no existing Odoo accounting setup exists.