Move to Cygnetree

Start with an inventory

Do not begin by uploading whatever file is easiest to find. First list every category the old system holds:

• people, businesses, households, vendors, and relationships;
• projects, deals, jobs, pipelines, stages, tags, custom fields, tasks, and notes;
• contracts, signatures, invoices, installments, payments, refunds, and receipts;
• forms, questionnaires, templates, packages, automations, and scheduling rules;
• messages, email history, appointments, files, and portal links; and
• active, archived, cancelled, test, and duplicate records.

Record the source counts in Settings → Migration center before the final import. Keep each source in its own migration workspace. Source IDs remain attached to imported people and projects, and source stages remain attached to projects, so retrying the same file is safe and later workflow improvements do not rewrite history.

Export files contain personal and financial information. Store them in a controlled location, restrict access, avoid emailing unencrypted archives, and record where the accepted archive lives.

Choose export, guided, or archive-first

Every source workspace supports three routes:

• Use available exports for reliable people, project, deal, job, or module files.
• Guided manual move when the source has no complete export. Inventory each area, use mapped CSV where possible, and rebuild active behavior through Cygnetree builders.
• Archive historical work when only active records need to become native. Retain older or unsupported work as readable evidence.

These routes can be combined. The selected route records the operating plan; it does not disable importers or builders. For each migration area, choose Import, Rebuild, Archive, Exclude, or Unresolved. An unresolved or missing disposition prevents completeness approval.

Use the universal safe order

1. Export everything the source legally and technically permits.
2. Save an untouched copy and record the export date, filters, account, and operator.
3. Import people and organizations first, then resolve duplicate identities.
4. Recreate the source pipeline with its stage names unchanged.
5. Map projects, deals, or jobs to people and exact source stages.
6. Copy clean files and rebuild only the reusable templates and automations that are still needed.
7. Recreate future appointments, payment expectations, forms, and public entry points.
8. Test one real lifecycle without contacting a client or collecting money.
9. Freeze changes in the source, export the final delta, and reconcile every row.
10. Move website forms, scheduler links, email routing, and portal links.
11. Keep the source read-only through the chosen rollback and archive period.

Never recreate an old signature, transaction, delivery event, or read receipt as if Cygnetree observed it. Preserve that evidence in the source archive.

Prepare people and relationship CSV files

Import people before projects. The people importer accepts up to 1,000 rows and 5 MB per batch. Review every suggested mapping; a suggested column is never permission to import it blindly.

| Cygnetree field | Required | Rule | |---|---:|---| | Stable source ID | Yes | A provider record ID that remains unchanged across exports | | Full name or first/last name | Yes | At least one usable name mapping | | Email, phone, company | No | Exact email can safely link an existing active person | | Record type | No | Person, household, company, or venue | | Roles and tags | No | Separate multiple values with a pipe, semicolon, or comma | | Related source IDs | No | Use stable IDs from this source, never names or row numbers | | Relationship type and labels | No | Household, business, team, referral, or other |

Choose Keep existing Cygnetree details for a non-destructive first pass. That mode links an exact email match without overwriting it and skips a source ID already imported. Choose Update mapped source details only after reviewing the mapped columns; roles remain additive and tags merge.

Ambiguous emails, duplicate source IDs, different source IDs sharing one email, unavailable linked people, missing relationship IDs, and self-relationships remain in the review list. Correct the source file and retry. One Cygnetree person may retain an identity from more than one migration source, but only one ID from each source.

Each import creates a durable run summary. Review rows remain visible after a refresh and can be downloaded as a correction CSV. Retrying a stable source ID supersedes its earlier review row. If a row truly cannot be imported, an administrator may choose Archive only or Exclude deliberately, but must explain why; Cygnetree retains that decision in the migration and audit evidence. A disposition can account for an original source row without pretending it became a Cygnetree record; project dispositions retain the source row's active/archive classification.

Prepare project CSV files

The project importer accepts up to 500 rows and 5 MB per batch. After selecting a file, map these columns:

| Cygnetree field | Required | Rule | |---|---:|---| | Stable source ID | Yes | A value that remains unchanged across repeat exports | | Project or job name | Yes | Human-readable source name | | Primary client source ID or email | Yes | Same-source ID is preferred; exact email is a fallback | | Source stage or status | Yes | Must exactly match a stage in the selected import pipeline | | Event, start, or target date | No | Use YYYY-MM-DD | | Archived state | No | archived, closed, complete, true, yes, or 1 |

The mapping preview suggests common column names, but you must review them. A same-source client ID links the project even when no email is present. Unknown people and stages remain in the review list. Duplicate IDs inside the file are rejected, and an ID already imported from the same source is skipped instead of overwriting your Cygnetree work.

When a source does not export stable IDs, add a Source ID column to the untouched working copy. Use a deterministic value such as the source record URL slug or a documented export key—never the row number of a file that may be reordered.

Choose a source playbook

HoneyBook

Use the dedicated Switching from HoneyBook guide and select HoneyBook in the migration center. HoneyBook documents a contact spreadsheet and downloadable reports, but not one complete project export. The guided route uses a prepared source-preserving project inventory and explicitly accounts for contracts, invoices, files, communications, appointments, templates, automations, and entry points.

Dubsado

Dubsado documents CSV exports for clients and projects. Export each relevant project status or filter, include the client and project fields you need, and retain the original status text. The Dubsado export guide notes that only projects visible under the selected status and filters are included, so repeat the export for every active and archived segment and reconcile their combined totals.

Import Dubsado contacts first. Create a source pipeline with every project status, then map the project identifier, project name, client email, project status, date, and archived column. Export contracts, forms, and invoices as readable files where available; rebuild active templates and workflows only after comparing their intended behavior.

17hats

17hats provides a contact CSV export. Its official contact export guidance does not describe a complete project-and-artifact export. Import contacts by type or tag, then create a controlled project inventory with a stable source ID, client email, project name, stage, date, and archive state.

Download active documents and evidence project by project, record archive-only dispositions, and recreate only future appointments, open balances, and reusable workflows. Do not mark those artifacts imported merely because the contact exists.

HubSpot

Export contacts, companies, and deals as separate objects with Record ID and associations. HubSpot's record export documentation explains which properties and associations can be included; activities may require separate exports or APIs.

Import contacts and companies first. Treat deals as Cygnetree projects, map Deal Record ID as the stable source ID, and preserve the original pipeline and deal stage. Reconcile contact-company-deal associations before importing activities, tasks, notes, products, or payment-related records. Custom objects require their own inventory and disposition.

Zoho CRM

Export each required module separately and include Record ID, lookup fields, pipeline/stage fields, owners, and custom fields. Zoho's CRM export guide supports CSV and XLSX module exports and documents export limits and history.

Import Contacts and Accounts before Deals. Map the Deal record ID, name, primary contact email, stage, and closing date. Preserve the module name and original lookup IDs in the working archive so relationships can be reconciled. Export Notes, Activities, Products, Quotes, and other modules separately instead of flattening them into an ambiguous deal file.

Jobber

Jobber's client export guide supports CSV or vCard exports and includes contact information, properties, tags, and custom fields. Export all client segments and preserve property addresses because field-service jobs may depend on the service location rather than only the person.

Import people, businesses, and service locations first. Prepare a job inventory with stable Jobber IDs, client email, job name, status, scheduled or target date, and archive state. Inventory requests, quotes, visits, invoices, and recurring schedules separately; rebuild upcoming work and retain completed operational and payment evidence in the archive when it cannot be imported faithfully.

Spreadsheet or another CRM

Keep one source-of-truth workbook with separate sheets or CSV files for people, organizations, relationships, projects, stages, tasks, appointments, balances, and file references. Give every record a stable source ID and use the same IDs to represent relationships across files.

Start with the people migration template, project migration template, and invoice migration template. Their example rows are intentionally fictitious; delete them before importing. Estimated value uses minor units (250000 means USD 2,500.00) and must always include a three-letter currency.

The invoice template uses one row per payment or installment; rows sharing an invoice ID become one invoice with a payment plan. Invoice amounts are dollars (3000.00), dates use YYYY-MM-DD, and already-collected amounts go in the paid columns. Import people and projects before invoices so each invoice can find its client and project. Imported invoices are idempotent by invoice ID and never send payment reminders until you turn reminders on for them.

Import a small test batch first. If an export has no consistent identifiers, stop and define them before importing; names alone are not safe identity keys.

Handle what cannot be imported

Every source artifact needs one truthful disposition:

• Imported natively: Cygnetree stores the source ID and reconstructed record.
• Rebuilt and accepted: a current template or workflow was independently recreated and tested.
• Archived externally: the artifact remains readable in a controlled source archive.
• Intentionally excluded: duplicate, test, expired, or legally disposable data was reviewed.
• Needs review: ownership, identity, stage, balance, or completeness is unresolved.

Upload ZIP, CSV, JSON, PDF, Office, or text exports to the selected source workspace in the migration center, or record a controlled external archive location. Cygnetree-retained exports use your selected private storage and remain unavailable until checksum verification and malware scanning finish. They are never shared through the client or vendor portal.

Keep contracts, signature evidence, payment evidence, tax records, and regulated data according to counsel and accounting guidance.

Run the final delta and reconcile

Choose a source freeze time and stop editing the old system. Repeat the same exports with the same filters, then import only records added or changed since the previous run. Stable source IDs make repeat project imports idempotent, but edits to already imported records need explicit review rather than silent overwrite.

Download the reconciliation JSON. It contains the source-to-Cygnetree identities for people and projects, relationships expressed with source IDs, source totals, imported totals, active/archive splits, import runs, open review rows, archive dispositions, completed checks, freeze time, retention date, external archive reference, and retained-file checksums and safety states. The readiness check compares the selected source's people—not every person in the workspace—plus every project count, and refuses completion while a review row or migration-area disposition remains unresolved.

Before marking the archive verified, open a sample from a scan-cleared retained file or record and sample a durable controlled-drive folder or storage path. Do not paste a credential or temporary signed download URL. “Evidence complete” means the recorded checks agree; it is not an automatic instruction to cancel.

After reviewing the reconciliation export, record a completeness approval in the migration center. Type the workspace name and explain what you sampled. The approval fingerprints the current counts, imports, dispositions, checklist, archive checksums, and import history. If any of that evidence changes later, Cygnetree marks the approval stale and requires a new review.

Keep a rollback path

Before moving public entry points, record their old and new destinations. Keep the old account read-only, preserve DNS and integration settings, and decide how long new work can be routed back if a release blocker appears. Do not delete the source or its export archive during the rollback window.

After the acceptance owner approves the migration, remove obsolete public links, revoke unused tokens, document the cancellation date, and retain only the archive required by business, legal, privacy, and accounting policy.