Migration Checklist: Moving to Zoho CRM

Phase 0

Decide & Plan

Decisions that must be made before any extraction work starts.

• Document the in-scope Zoho CRM Modules. List every standard Module you will load (Leads, Accounts, Contacts, Deals, Tasks, Calls, Meetings, Notes, Products, Quotes, Sales Orders, Invoices, Cases, Campaigns, Vendors, Price Books) and every custom Module you will create. Anything not on this list is out of scope.

  Risk if skipped: Late-discovered Modules force schema changes mid-migration and trigger re-runs of upstream transform jobs.

• Pick the Zoho CRM edition before any provisioning. Edition gates storage ceiling (Free 5k records / 10 MB, Standard 100k records / 200 MB, Professional 10 GB, Enterprise 10–15 GB, Ultimate up to 30 GB for >200 users), Sandbox availability (Enterprise and above), Multi-Select Lookup fields (Enterprise and above), and custom field counts per Module.

  Risk if skipped: Choosing a lower edition than the data requires blocks Sandbox testing and many-to-many relationships entirely.

• Define the historical-data scope window. Decide how many years of closed Deals, completed Tasks, logged Calls, sent Emails, and Notes are in scope. Decide whether Attachments are in scope or stay in the legacy archive.
• Decide the audit-timestamp strategy. Zoho CRM stamps Created Time and Modified Time at the moment of insert and does not let bulk imports override them. Pick one strategy and document it: capture source CreatedDate in a custom date field per Module, or accept that Created Time equals migration date.

  Risk if skipped: Without a decision, reports and activity timelines look like every record was created on cutover day.

• Document data-residency and compliance requirements. Zoho operates regional data centers (US, EU, IN, AU, JP, CN, CA). Confirm which DC the org must live in, GDPR enablement for Leads/Contacts/Vendors, and whether SOC 2 + HIPAA scope is required.

  Risk if skipped: Provisioning in the wrong DC cannot be reversed by moving data later — it requires a fresh org and a second migration.

• Name a single accountable migration owner (DRI). One person signs off on Phase 0, Phase 4 sandbox results, and Phase 6 reconciliation. No committee.
• Set the cutover date, time, and source-system freeze window. Pick a low-volume window. Confirm with sales, support, and finance that no campaigns, billing runs, or quarter-end closes overlap.
• Write the success criteria. Concrete pass/fail statements: total record count per Module matches source within 0.1 percent, total open pipeline value matches source within $1, every active user can log in and see their assigned records.

  Risk if skipped: Without written criteria, the migration drags on indefinitely because nobody can declare it done.

• List explicitly out-of-scope items. Examples: source-system custom dashboards (rebuild manually post-cutover), source-system Workflow Rules (rebuild in Zoho), deleted records in the legacy recycle bin, system-audit logs older than 12 months.

Phase 1

Pre-Migration Prep

Everything that must be true before the first byte leaves the source.

Phase 2

Source Export

Get all data out of the source system in a form you can transform.

• Export Leads as CSV with all standard and custom fields. Include source primary key as a column so it can be loaded into the destination External ID field.
• Export Accounts (Companies) as CSV with all fields plus parent-account ID.
• Export Contacts as CSV with all fields plus the Account ID lookup.

  Risk if skipped: Exporting Contacts without the Account foreign key forces a manual re-association later, which is error-prone at volume.

• Export Deals as CSV with Layout, Pipeline, Stage, Closing Date, Amount, and Account/Contact lookups. Include any deal-stage-history fields the source surfaces.
• Export Tasks, Calls, and Meetings as three separate CSVs. Each has a different schema in Zoho CRM. Include the parent record ID (What ID / Who ID equivalents).
• Export Notes as a CSV linked to their parent record IDs. Note content can include line breaks and quotes; ensure the exporter quotes correctly.
• Export Email message history with parent record associations. Zoho CRM has no native bulk import for past emails into the email-history timeline. Plan to load them into a custom Email Log Module or attach as Notes with an Email Date custom field.

  Risk if skipped: Treating email history as a standard Note loses the threading and sender metadata.

• Export attachment metadata: file name, size, MIME type, and parent record ID. Separate file from metadata; both are required at re-upload time.
• Download attachment binaries to a staging bucket. Per-record attachment cap in Zoho CRM is 100 MB total, with per-file cap of 20 MB. Flag any oversize file for the Phase 3 decision.

  Risk if skipped: Files larger than the per-file cap will not load and silently leave records unlinked.

• Export the full User list with email, role, profile, and active/inactive flag.
• Export source Pipeline and Stage definitions as a reference document. This becomes the source side of the Layout-Pipeline-Stage triple mapping in Phase 3.
• Export Products, Price Books, Quotes, Sales Orders, and Invoices if in scope.
• Capture screenshots of source dashboards, reports, and Workflow Rules. These do not migrate. They will be rebuilt manually in Phase 7.
• Record the exact UTC timestamp of each export. This is the baseline for the Phase 5 delta export.

Phase 3

Transform & Map

The data-engineering core. Take raw exports and produce Zoho-shaped files.

Phase 4

Sandbox Test Migration

Catch every problem in Sandbox before it costs you in production.

• Load a 1–5 percent representative sample of every in-scope Module into the Sandbox. Use the Data Migration wizard or Bulk Write depending on planned production path. Match the production method exactly.
• Validate field-by-field on 10 random Sandbox records per Module. Open each record in the UI and compare every field to the source export. Document any discrepancy.

  Risk if skipped: Sampling fewer than 10 records misses field-level drops that only surface on certain record subtypes.

• Test the Layout-Pipeline-Stage triple by loading Deals across every Pipeline. Confirm every combination produces a loaded Deal, not a skip.

  Risk if skipped: An untested triple discovered in production blocks the entire Deal-load wave.

• Test picklist reference values against display labels. Confirm the value lands in the right picklist option by inspecting the underlying reference value, not just the rendered UI label.
• Test datetime timezone handling on at least 3 records. Pick records with timestamps near midnight to surface off-by-one-day errors.
• Test special-character handling: emoji, accents, quotes, newlines. Pick at least 5 source records containing each.

  Risk if skipped: Character-encoding bugs are invisible until a user opens the record and sees mojibake.

• Test Multi-Select Lookup associations end to end. Load both sides and the junction; confirm the related list shows the expected counts on each side.
• Test Attachment upload on at least 25 records. Verify file integrity (size matches source) and that the attachment appears in the related list.
• Run a Bulk Write job at full volume against Sandbox where possible. Bulk Write caps at 200,000 records per job and 5 concurrent jobs per org. Time the job end-to-end and extrapolate to production volume.

  Risk if skipped: A 'works on 5 percent' test does not surface throughput cliffs that only appear at 50,000+ records.

• Confirm the Phase 3 audit-trail strategy actually worked. Spot-check the 'Source Created Date' custom field is populated on every record.
• Have a domain expert from sales spot-check Deal records in Sandbox. Real users find issues data engineers miss: missing notes, wrong stage names, lost Account associations.
• Have a marketing user spot-check Lead and Contact records in Sandbox. Validate email opt-out flags, campaign associations, and lead source values.
• Capture timing for every Bulk Write job for production planning. Job submit → completion times let you size the production cutover window realistically.
• Get written sign-off on Sandbox results before scheduling production cutover. Email or ticket; do not proceed on verbal approval.

  Risk if skipped: Verbal sign-offs evaporate when reconciliation surfaces an issue post-cutover.

Phase 5

Production Cutover

Tightly sequenced execution window. Densest cluster of risk.

• Confirm source-system freeze. Inspect source-system audit logs to verify no record-modifying activity in the last hour.
• Take the final delta export of every in-scope object. Same exporter as Phase 2, same field set, new timestamp suffix on filenames.

  Risk if skipped: Skipping the delta loses every record created between Phase 2 export and cutover.

• Confirm Workflow Rules, Assignment Rules, and Blueprints are paused. Spot-check the Setup UI. Inadvertent activation between Phase 1 and Phase 5 is a common cause of surprise side effects.

  Risk if skipped: An active welcome-email workflow at cutover sends thousands of accidental emails in minutes.

• Load Users first (or confirm Users were created in Phase 1). Users must exist before any Owner field can resolve.
• Load parent Modules before child Modules. Order: Accounts → Contacts → Deals → Tasks/Calls/Meetings/Notes → Attachments → custom child Modules. Each layer references IDs created in the previous layer.

  Risk if skipped: Out-of-order loads leave lookup fields blank with no error and require a second pass to repair.

• Use upsert keyed off External ID for every load step that supports it. The per-call upsert path accepts 100 records per batch; Bulk Write upsert handles up to 200,000 per job. Idempotent reruns will not duplicate records.

  Risk if skipped: Insert-only loads on partial failure create duplicate records on retry.

• Capture the Bulk Write job ID, row count, and error log for every load step. Store these in a cutover run-book alongside timestamp and operator name.
• Cross-check destination row counts against source row counts at each step. Stop the cutover if any per-Module count differs by more than the agreed tolerance (typically 0.1 percent).

  Risk if skipped: Pushing through with an unexplained count delta makes Phase 6 reconciliation impossible.

• If any step fails, halt — diagnose — fix the transform — re-run idempotently. Never push partial data through to the next step.
• Re-enable Workflow Rules, Assignment Rules, and Blueprints after all loads complete. Document the exact reactivation time in the run-book.
• Run a Blueprint state-correction pass if required. If Blueprints were disabled at load time, walk each Deal through the appropriate state transition via Deluge or manual UI action.
• Snapshot the production org backup immediately after cutover completes. Use Zoho CRM's Data Backup feature. This is your rollback point if Phase 6 surfaces a fatal issue.

  Risk if skipped: Without a clean post-load snapshot, partial rollback requires per-record manual cleanup.

Phase 6

Validate

Prove the migration was correct before letting end users in.

Phase 7

Post-Migration Cleanup

Wrap up so the team can move on.

• Communicate go-live to all end users. Login URL, who-to-ask-for-help, link to the role-specific training recording.
• Run live training sessions segmented by role. Sales reps, sales managers, marketing, support, and admins each get a 30–60 minute focused session.
• Set the source system to read-only and announce the date. Read-only prevents accidental new writes that would never reach Zoho.
• Rebuild Workflow Rules in Zoho CRM. Workflow Rules do not migrate from any source system. Use the Phase 2 screenshots as the spec.
• Rebuild Assignment Rules and territory definitions.
• Rebuild Blueprint state machines for any process that needs them.
• Rebuild dashboards and standard reports. Reports do not migrate. Recreate the most-used 5–10 first, then expand.
• Rebuild any Deluge custom functions or scheduled jobs from the source automations. Source-system scripts (Apex, custom code) have no direct port; rewrite in Deluge.
• Re-enable integrations: email sync, calendar sync, marketing automation, BI tools. Run each integration in dry-run mode first to confirm no duplicates are created against migrated records.

  Risk if skipped: Marketing-automation re-sync without External-ID checks duplicates every contact.

• Configure the Zoho CRM Data Backup schedule. Set automatic backups per the retention policy decided in Phase 0.
• Schedule a 30-day post-migration retrospective. Capture what went well, what didn't, and update the migration runbook for the next org.
• Document the source-system decommission date. Typical pattern: 90 days read-only, then archive the final export to long-term storage and cancel the subscription.
• Archive all source-system exports and Zoho CRM migration logs to long-term storage. Retain per the legal-hold and retention policies from Phase 0.

  Risk if skipped: Discarding exports too early eliminates forensic options if a data-quality issue surfaces months later.

• Close the migration project formally. Final status report, lessons-learned doc, project closure.