CRM migration

Migrate from Myprosperity to Odoo CRM

Field-level mapping, validation, and rollback between Myprosperity and Odoo CRM. We move data and schema; workflows are rebuilt natively in Odoo CRM.

Myprosperity logo

Myprosperity

Source

Odoo CRM

Destination

Odoo CRM logo

Compatibility

100%

12 of 12

objects map 1:1 between Myprosperity and Odoo CRM.

Complexity

BStandard

Timeline

48–96 hours

Rollback included Accuracy guarantee Field-level validation

Overview

What this migration involves

Myprosperity organizes client data around a branded wealth portal: personal details, financial holdings, property valuations, vehicle records, and multi-party relationship tags (Accountant, Lawyer, Owner). Odoo CRM has no native wealth-management module — the equivalent model uses `res.partner` for contacts and companies, `crm.lead` for pipeline opportunities, and Odoo Studio custom fields for financial metrics. We map Myprosperity's `relationship` property to Odoo's `partner_id` contact-type tags, financial profile fields to custom `x_` fields on `res.partner`, and property/vehicle valuations to custom opportunity fields. Annature eSignature documents are re-uploaded to Odoo Documents. Workflow rules in Myprosperity are platform-native and cannot migrate — we export their definitions as a rebuild reference for Odoo Action Rules or Automate. The migration runs via Odoo's XML-RPC API with scoped read access to Myprosperity; a 24–48 hour delta-pickup window captures in-flight changes at cutover. Audit logging and one-click rollback are included. We also map Myprosperity's practice-portal users to Odoo `res.users`, preserving create dates to maintain the full client timeline from day one in Odoo's activity log. All property and vehicle valuations are translated into custom fields, ensuring no financial data is lost during the transition.

Field-level fidelity

Every standard and custom field arrives verified.

Schema-aware mapping

AI proposes the map; you confirm before any record moves.

Relationships preserved

Parent–child, lookups, and ownership stay linked.

Full activity history

Calls, emails, meetings — with original timestamps.

Attachments & notes

Documents, uploads, and inline notes move with the record.

Why teams make this switch

Two sides of the same decision

Leaving

Myprosperity logo

Myprosperity

What's pushing teams away

  • Primary market is Australia (myprosperity.com.au with a UK arm); advisors and firms in North America have limited local data-feed coverage and support.
  • Pricing is not publicly published — sales-led model slows procurement for firms used to transparent SaaS tiers.
  • Heavy reliance on bank/investment data feeds means feature value drops sharply when an Australian institution discontinues feed support.
  • Power users requesting deep customisation beyond standard wealth views and goal types may need third-party planning tools alongside myprosperity.
  • Property and investment data quality depends on third-party providers — outages or stale feed updates surface as client-facing issues.

Choosing

Odoo CRM logo

Odoo CRM

What's pulling them in

  • Teams choose Odoo CRM for its modular architecture — one base install with one-click app additions means they can adopt CRM alone and add accounting, inventory, or sales later as the business grows.
  • Small businesses pick Odoo because the Community edition is free and open-source, with no per-user or contact limits, allowing full evaluation before committing to a paid Enterprise tier.
  • The drag-and-drop Kanban pipeline and AI lead scoring are highlighted across G2 reviews as concrete features that make lead management faster and more visual than spreadsheet-based workflows.
  • Odoo's native integration with email, live chat, SMS, VoIP, and WhatsApp means inbound leads from multiple channels feed into a single pipeline without third-party middleware.
  • Companies in retail, supply chain, and construction value that Odoo's CRM module shares the same PostgreSQL database and UI as its ERP modules, eliminating data silos between sales and operations.

Object mapping

How Myprosperity objects map to Odoo CRM

Each row shows how a Myprosperity object lands in Odoo CRM, including any object-level transformations, lookup resolution, or schema-design dependencies.

Typical mapping — final map is confirmed during the sample migration step.

Myprosperity

Person (individual client)

maps to

Odoo CRM

res.partner

1:1
Fully supported

Myprosperity stores individuals as person records with name, email, phone, address, and a relationship tag. Odoo's `res.partner` model handles both people and organisations — individual clients map 1:1. The Myprosperity `relationship` integer enum (0=Owner, 1=Accountant, 2=Lawyer, 3=Wife, etc.) must be decoded and written to Odoo's `function` field or a custom contact-type tag.

Myprosperity

Company / Business entity

maps to

Odoo CRM

res.partner (company_type = 'company')

1:1
Fully supported

Myprosperity company records map to Odoo `res.partner` with `company_type` set to 'company'. The `name` field maps directly; address fields follow Odoo's standard street/city/state/zip structure. If the Myprosperity record links multiple persons to one company, Odoo's `child_ids` relation on the company partner record represents the same hierarchy.

Myprosperity

Financial Profile / Net-Worth Summary

maps to

Odoo CRM

Custom fields on res.partner

1:1
Fully supported

Myprosperity aggregates total assets, total liabilities, and net worth as a client summary. Odoo CRM has no native equivalent. We create custom fields `x_total_assets`, `x_total_liabilities`, `x_net_worth`, and `x_financial_profile_notes` on `res.partner` using Odoo Studio. Data type matches source (monetary fields for dollar amounts).

Myprosperity

Property (real estate holding)

maps to

Odoo CRM

Custom fields on crm.lead

1:1
Fully supported

Each Myprosperity property record (address, type, value, loan amount, loan balance, owner type) becomes a set of custom fields on the linked `crm.lead` in Odoo: `x_property_address`, `x_property_type`, `x_property_value`, `x_loan_original`, `x_loan_balance`, `x_owner_type`. Clients with multiple properties generate multiple opportunity records or use Odoo's inline one2many subview.

Myprosperity

Vehicle record

maps to

Odoo CRM

Custom fields on crm.lead

1:1
Fully supported

Myprosperity vehicle records (registration, make, model, year, value, loan balance) map to Odoo `crm.lead` custom fields: `x_vehicle_registration`, `x_vehicle_make`, `x_vehicle_model`, `x_vehicle_year`, `x_vehicle_value`, `x_vehicle_loan_balance`. Owner resolution on the `partner_id` field links the vehicle record to the correct `res.partner`. Each vehicle associated with a client creates a separate opportunity record in Odoo, or multiple vehicles can be represented as multiple field groups within a single opportunity record depending on the client's Odoo pipeline design.

Myprosperity

Document / File attachment

maps to

Odoo CRM

ir.attachment / Odoo Documents

1:1
Fully supported

Myprosperity document store files are downloaded and re-uploaded as Odoo `ir.attachment` records linked to the corresponding `res.partner`. The original filename and create date are preserved. If the Odoo instance runs Enterprise with the Documents app, files route there for full-text search and eSignature workflows.

Myprosperity

Annature eSignature record

maps to

Odoo CRM

Odoo Sign or ir.attachment

1:1
Fully supported

Annature is Myprosperity's native eSignature partner. Signed documents are retrievable from Myprosperity's document store, but the Annature audit trail (signer identity, timestamp, IP address) has no Odoo Sign equivalent. We re-upload the final signed PDF to Odoo as an `ir.attachment` and flag the record with a custom `x_signed_via_annature` boolean. Rebuilding Odoo Sign envelopes is a manual post-migration step.

Myprosperity

Practice Portal user / Staff member

maps to

Odoo CRM

res.users

1:1
Fully supported

Myprosperity Practice Portal staff licences map to Odoo `res.users` accounts. Email-address matching links each Myprosperity owner/staff record to an Odoo user. Myprosperity's Practice Portal roles (admin, adviser, compliance) do not map to Odoo security roles — Odoo access rights must be configured manually post-migration based on the staff member's intended Odoo responsibilities.

Myprosperity

Note / Activity log entry

maps to

Odoo CRM

mail.message / crm.lead

1:1
Fully supported

Myprosperity notes attached to a client profile migrate as Odoo `mail.message` records on the linked `res.partner` or `crm.lead`. The original author and create timestamp are preserved in Odoo's message metadata. Notes tagged as compliance-related are flagged with a custom `x_compliance_note` tag so advisers can identify them in the Odoo activity stream.

Myprosperity

Deal / Client engagement record

maps to

Odoo CRM

crm.lead

1:1
Fully supported

Myprosperity tracks active client engagements as deal records with name, stage, estimated value, and close date. Each engagement maps to a `crm.lead` in Odoo. The Myprosperity deal stage (Prospecting, Quoting, Active, Review) translates to the nearest Odoo CRM stage via value mapping. Estimated value maps to `crm.lead.expected_revenue`; the source deal amount is also written to a custom `x_source_deal_amount` field.

Myprosperity

Pipeline Stage

maps to

Odoo CRM

crm.stage

1:1
Fully supported

Myprosperity deal pipeline stages (Prospecting, Proposal, Negotiation, Won, Lost) are mapped value-by-value to Odoo CRM stage records. Each Odoo stage must be created in the target CRM before migration runs so the `stage_id` foreign key resolves correctly. Probability and team-assignment fields on the Odoo stage record are set to match the closest Myprosperity stage intent.

Myprosperity

XPLAN / Accounting integration link

maps to

Odoo CRM

Odoo Accounting module (no_equivalent)

1:1
Fully supported

Myprosperity integrates with XPLAN (practice management), Macquarie investment feeds, and Xero Practice Manager for data imports. These integrations are platform-specific and do not have Odoo equivalents — they must be rebuilt as Odoo API connections or manual import routines post-migration. We export the current integration configuration as a reference document for your Odoo implementation partner.

Gotchas + challenges

What specifically takes care here

Platform-specific issues from each side, plus the pair-specific challenges that don't show up on either platform's page on its own.

Myprosperity logo

Myprosperity gotchas

High

No bulk data export endpoint requires iterative API polling

High

Tier determines data vintage, not just feature availability

Medium

Document storage caps can silently block large migrations

Medium

Client Relationship roles have a hard-coded integer schema

Medium

eSignature packages are stored as stateful workflow objects, not plain documents

Odoo CRM logo

Odoo CRM gotchas

High

Odoo.sh version gating blocks assisted migrations from trial

High

Enterprise modules fail to install on Community after database restore

Medium

Custom module view inheritance breaks between Odoo major versions

Medium

Custom fields risk losing their application context on Community

Low

API access for Community is gated behind the Custom Plan

Pair-specific challenges

  • Relationship integer enum has no Odoo native equivalent — manual tag work required

    Myprosperity encodes agent-to-client relationships as integers (0=Owner, 1=Accountant, 2=Lawyer, 3=Wife, 4=Husband, 5=Child) in its API. Odoo `res.partner` has a freeform `function` field and a tag system but no native relationship-type taxonomy. We map each integer to a human-readable `function` string and apply partner tags during migration, but the full Myprosperity relationship graph — particularly where one person holds multiple roles (Accountant AND Lawyer for the same client) — requires post-migration validation in Odoo to confirm the tag set is complete and accurate for each partner record.

  • Financial property objects have no native Odoo CRM equivalent — custom field proliferation risk

    Myprosperity stores real estate properties and vehicles as top-level objects with valuation, loan-balance, and owner-type fields. Odoo CRM has no native equivalent — each financial property migrates as a set of Odoo Studio custom fields on the linked `crm.lead`. Clients with 10 properties and 5 vehicles generate 150+ custom field values per opportunity record. If the Odoo implementation uses the Odoo Community edition without Studio access, these fields require a custom module, which adds implementation cost. We document every custom field created before the migration run so the Odoo administrator can review and consolidate duplicates before data lands.

  • Annature eSignature audit trails do not transfer to Odoo Sign

    Myprosperity's embedded Annature integration stores signed documents with Annature's own audit trail (signer name, email, IP address, timestamp, certificate hash). Odoo Sign stores its own audit trail on signed documents. When documents are downloaded from Myprosperity and re-uploaded to Odoo as PDF attachments, the Annature audit trail is lost. We re-upload the final signed PDF and flag the record with `x_signed_via_annature`, but any legal or compliance team that needs the Annature signing history must retain access to the Myprosperity account or export Annature's own certificate before the account is closed.

  • Odoo API rate limits and External API availability depend on the Odoo plan tier

    Odoo's External API (XML-RPC) is available on all Odoo plans, but API rate limits and batch-import features vary. Odoo Community deployments require the Odoo RPC interface directly; Enterprise deployments with Odoo.sh have additional API quotas. The Myprosperity API is a REST endpoint with its own rate-limit profile. We throttle writes to Odoo's XML-RPC endpoint to avoid HTTP 429 errors and batch records in groups of 500 to stay within Odoo's default request limits. If the destination Odoo instance uses Community with a self-hosted database, we confirm the RPC endpoint is publicly accessible or VPN-routed before migration runs.

  • Practice Portal staff licences do not map to Odoo user seats — permission model is entirely different

    Myprosperity Practice Portal staff licences are scoped to the practice-level efficiency tools (document management, task management, client portal admin). An Odoo `res.users` account is a full database seat with access rights to every enabled app. A Myprosperity staff member who only needs document-signing access requires an Odoo user licence even if they never touch the CRM pipeline. This means the number of Odoo licences post-migration often exceeds the number of Myprosperity Practice Portal licences the practice previously held. We flag this discrepancy during the scoping call so the practice can right-size its Odoo user count before migration.

Migration approach

Six steps for a successful Myprosperity to Odoo CRM data migration

  1. Scoping audit and Odoo schema preparation

    We audit the Myprosperity account for total record counts across person, company, property, vehicle, and deal objects; note all custom properties and their data types; and identify any Annature-signed documents. Based on the audit, we deliver a schema plan listing every Odoo Studio custom field to be created (with data type, label, and placement on `res.partner` or `crm.lead`), every Odoo CRM stage to be pre-created, and every Myprosperity relationship integer to be mapped to an Odoo function string. The practice creates these fields in their Odoo test environment before we begin data work.

  2. Owner and user resolution

    Myprosperity owner IDs are resolved by email address match against existing Odoo `res.users` records. Any Myprosperity staff member or adviser with a Myprosperity account who does not have a corresponding Odoo user is flagged as an unmatched owner. The practice either creates the Odoo user account before migration or designates a fallback owner (advisory principal) to receive orphaned records. No record migrates without a valid Odoo owner assignment.

  3. Sample migration with field-level diff

    A representative sample — typically 50–100 records spanning person, company, property, vehicle, and deal objects — is migrated to the Odoo test database first. We generate a field-level diff showing source value versus destination field value for every mapped column. The practice reviews the diff to confirm relationship-tag accuracy, financial field placement, and pipeline stage mapping before the full run commits. Any field mapping errors are corrected in the migration script before the production run.

  4. Full migration with delta-pickup cutover

    The full Myprosperity dataset migrates to the production Odoo instance via Odoo's XML-RPC API in sequenced batches: `res.partner` records first (persons and companies), then `crm.lead` opportunities with financial property custom fields linked by partner ID. A 24–48 hour delta-pickup window opens at cutover — FlitStack AI monitors Myprosperity for any records created or modified during this window and applies the delta to Odoo before final reconciliation. Audit logging captures every write operation. One-click rollback reverts the Odoo database to its pre-migration state if reconciliation identifies unexpected gaps.

Platform deep dives

Context on both ends of the pair

Myprosperity logo

Myprosperity

Source

Strengths

  • Client portal with white-labelled mobile app builds brand visibility for accounting and advisory practices
  • Integrates with Xplan, Xero Practice Manager, and MYOB for practice-side data import
  • Investment feed aggregation from XPLAN and Macquarie consolidates client wealth data in one view
  • Document e-signing via Annature integrates into the client workflow natively
  • Pro tier provides live bank feed syncing and monthly valuation updates

Weaknesses

  • No publicly documented bulk export or migration API — data extraction relies on per-record API calls or CSV/XPM import templates
  • Starter tier limits bank feeds to one-time sync and valuations to one-time snapshots, reducing the richness of migrated financial history
  • Tier-gated features (Fact Finds, Survey Analytics, Advanced Mobile Branding) mean not all clients on a plan have equivalent data
  • Document storage caps (50–200GB) may require archival or selective migration for high-volume practices
  • Practice Portal staff licenses and client subscription limits are tied to the current tier — over-importing will trigger an upgrade
Odoo CRM logo

Odoo CRM

Destination

Strengths

  • Modular open-source architecture lets teams start with CRM and add ERP apps as needs grow, all sharing one PostgreSQL database.
  • Free Community edition with no contact limits and full source code access means zero licensing cost for evaluation and small deployments.
  • Drag-and-drop Kanban pipeline with AI lead scoring gives a visual, prioritized view of the sales funnel without requiring custom configuration.
  • Native integrations with email, live chat, SMS, VoIP, WhatsApp, and social media feed all inbound leads into a single unified inbox.
  • Active Odoo Community Association (OCA) maintains dozens of community-maintained modules on GitHub for extended functionality.

Weaknesses

  • Gmail and email integration reliability is a recurring complaint — threads drop and conversations scatter across inboxes, disrupting sales team workflows.
  • Enterprise edition pricing stacks quickly: multiple apps at per-user rates ($25–$50/user/month) plus Odoo.sh hosting costs more than many SMBs anticipate.
  • Setup and configuration complexity increases significantly once custom fields, automation rules, and multiple installed modules are in play.
  • Odoo.sh trial databases run on a version (e.g., 18.3) that is not directly migratable to Odoo.sh, blocking the assisted migration path Odoo advertises.
  • Version upgrades between major Odoo releases (e.g., 17→18) frequently break custom module view definitions and XPath expressions, requiring manual remediation.

Complexity grading

How hard is this migration?

Standard CRM migration. 1 of 8 objects need a mapping; the rest are 1:1.

B

Overall complexity

Standard migration

Derived from compatibility, mapping clarity, API constraints, and data volume across Myprosperity and Odoo CRM.

  • Object compatibility

    B

    1 of 8 objects need a mapping; the rest are 1:1.

  • Field mapping clarity

    C

    Field mapping is derived from defaults — final spec confirmed during the sample migration.

  • Timeline complexity

    B

    8-object category — typical timelines run 2–7 days end-to-end.

  • API constraints

    B

    Myprosperity: Not publicly documented.

  • Data volume sensitivity

    B

    Myprosperity doesn't expose a bulk API — REST + parallelization used for high-volume runs.

Estimator

Estimate your Myprosperity to Odoo CRM migration cost

Rule-based pricing — no per-record fees, no manual quotes. Migrations over 2M records are scoped individually.

Step 1

What are you migrating?

Pick a category, then your source and destination platforms.

Category

FAQ

Frequently asked questions about Myprosperity to Odoo CRM data migrations

Answers to the questions buyers ask most during Myprosperity to Odoo CRM migration scoping. Not seeing yours? Book a call.

Can't find your answer?

Walk through your Myprosperity to Odoo CRM migration with a real engineer — 30 minutes, free, written quote within 24 hours.

Book a free 30 minute consultation

Most Myprosperity-to-Odoo migrations complete in 48–96 hours of clock time for fewer than 25,000 total records. The longest phase is Odoo Studio field creation for financial property and vehicle custom fields — scoping and setting up 50+ custom fields across `res.partner` and `crm.lead` takes 3–5 days before any data moves. Heavier setups with over 100,000 records or complex financial property records extend the full timeline to 7–14 days.

Adjacent paths

Related migrations to explore

Ready when you are

Move from Myprosperity.
Land in Odoo CRM, intact.

Tell us record counts and timeline. We'll come back with a written quote inside 1 business day — no commitment, no sales pitch.

Accuracy guarantee Rollback included Quote in 1 business day