How we built a migration engine that moves an entire CRM between Salesforce and Zoho CRM from a single button click, and what happened when we used it on a real Salesforce org: about 10 modules averaging 300,000 to 400,000 rows each, around 30 functions, around 25 workflows and Blueprints, all rebuilt natively in Zoho. A Microsoft target is in development.
Rebuilt natively in Zoho, plus a few million records
~55 automations
The Challenge
Moving a CRM from Salesforce to Zoho, or the other way round, looks like a data problem and turns out to be an architecture problem. Exporting records is the easy part. Zoho's help article on importing from Salesforce describes a CSV-based path for standard and custom modules, attachments and tags. It is a data import. It does not describe rebuilding your workflows, your Apex code, your page layouts or your validation rules, and those are exactly the things that took years to tune. In most migrations they get rebuilt by hand, screen by screen, by whoever is left holding the project. The two platforms are built differently, so nothing maps one-to-one. Salesforce business logic lives in Apex, a proprietary, strongly typed, Java-like language with triggers, governor limits and a 75% test-coverage rule before anything reaches production. Zoho's native language is Deluge, a scripting language with very different syntax and execution limits, and Zoho's v8 API now also lists Java, Node.js and Python for functions. Salesforce automation has moved from Workflow Rules and Process Builder, whose end of support date was December 31, 2025, to Flow, which can loop, branch and call external APIs. Zoho splits the same ground between workflow rules, Blueprints (guided, user-driven stages with enforced transitions) and functions. A Flow is not a Blueprint, and a Blueprint is not a workflow rule. Someone has to decide, for every automation, which Zoho construct carries the same intent. On top of that there is scale and order. Salesforce exposes structure through its Metadata API and data through REST and Bulk API 2.0, each with its own limits (Bulk API 2.0 ingest is capped at 15,000 batches and 150 million records per rolling 24 hours). Zoho's v8 API exposes modules, fields, layouts, workflows, Blueprints and functions programmatically, which makes automation possible, but only if the structure is created before a single record is loaded. Load data into a half-built target and lookups, picklists and required fields break. The client in this engagement made all of that concrete. Their Salesforce org held about ten core modules, each averaging roughly 300,000 to 400,000 rows, with the largest at around 600,000. On the logic side it carried around 30 custom functions, around 25 workflows and a set of Blueprints. Rebuilding that by hand, and then loading a few million records into it cleanly, is the kind of project that normally runs for weeks or months. Published migration guides commonly quote weeks for a mid-size org and months for a heavily customized one, and most of that time is configuration rather than copying rows. We wanted one repeatable process instead of a fresh bespoke project every time a client asked to switch platforms, and it had to work in both directions, because clients move from Zoho to Salesforce as often as the reverse.
What We Built
We built a migration engine with a deliberately small surface for the person running it. The operator enters the connection details for the source and the target: the API credentials and OAuth client details for Salesforce, and the same for Zoho. Then they press one button. Everything after that is the engine's job. The engine works in the same order a careful human would, structure first and data last. It reads the source org's metadata, starting with the modules and objects and their fields, then page layouts, validation rules and workflow automation, and recreates that structure on the target through the target's own APIs. Only when the structure is in place does it move records, so every lookup, picklist and required field has somewhere to land. The hard part is the logic, and this is where the AI layer earns its place. We built a large language model layer that understands how Salesforce constructs behave and expresses them in the target platform's native terms, rather than translating text line by line. Functions are converted into the target's native language. Flows and legacy workflow rules are read for what they do, meaning what triggers them, what they check and what they change, and rebuilt as workflow rules, Blueprints or functions on the Zoho side. Validation rules and layouts are carried across the same way. Workflows were the most complicated part of the whole system, because the two platforms disagree about how automation should be shaped. On the client migration, the engine moved the full set of roughly ten modules with their fields, layouts and validations, then rebuilt around 30 functions and around 25 workflows, along with the Blueprints, and finally migrated the records. Every one of the functions landed as a native Deluge function. The engine can also target Node.js, Java or Python functions where a job calls for them, for example heavy record-walking or messy JSON handling, but this org did not need any of that, so nothing was pushed beyond Deluge and the client's team gets automation in the language Zoho admins already work in. The same engine runs in reverse, Zoho to Salesforce, with the translation layer working in the other direction. A third target, the Microsoft ecosystem, is currently in development on the same architecture. The adapters change per platform, but the pattern of connect, read structure, translate logic, rebuild structure and then load data stays the same.
The Result
The client's Salesforce org arrived in Zoho CRM as a working system rather than an empty one: around ten modules carrying roughly 300,000 to 400,000 rows each on average, the largest near 600,000, so a few million records in total, plus around 30 Deluge functions, around 25 workflows and the Blueprints that run their processes. That is more than 55 automations, which would otherwise have been recreated one by one from screenshots and documentation, and the whole thing started from a single button press after the credentials were entered. The configuration work that normally absorbs most of a migration, the part that a plain data import leaves to people, was done by the engine, and the records followed once the structure existed. For the client, platform choice stops being a one-way door, and for us a migration now starts from a rebuilt, running system instead of a blank screen and a spreadsheet of field mappings. The client's name stays confidential, and we have not attached timing or accuracy percentages here, because we only publish figures we can stand behind. The numbers above, the module count, row volumes, functions and workflows, are what was actually moved. Next up is the Microsoft target, now in development on the same connect, translate and rebuild approach. If you are weighing a move between Salesforce, Zoho or Microsoft and want to see how your own org would translate, we are happy to walk through it.
Want something like this built for you?
Tell us about your workflow and we'll put together a tailored plan.
Book a Free Auditarrow_forward