Why businesses outgrow a customized Zoho system
Zoho is capable software, and Zoho CRM and Zoho Creator can be customized a long way. The trouble comes from how customizations pile up. Each time the business needs something new, someone adds a custom field, a custom module, a Creator app or a script written in Deluge, Zoho's scripting language. Each change fixes the problem in front of it.
After some years, important business rules live in places nobody reviews, and only the consultant who wrote them knows how they fit together. Every change goes through that consultant, and each one carries more risk because it touches rules the business cannot see. That is usually when a business starts looking for the way out, and when it needs to be careful about what it takes along.
Where your Zoho data and rules live
An export of your main Zoho modules is the start of the inventory. Before you approve any migration plan, list every place your business data and rules are kept. This table is a starting point.
| Where to look | What it holds | What to check |
|---|---|---|
| Standard modules such as accounts, contacts, quotes, orders and products | Your core records | Every module is exported, including records closed years ago |
| Custom modules and custom fields | Things your business tracks that Zoho had no place for | Each one is listed with the business need it serves |
| Attachments and notes | Files and comments on records, such as signed orders | They are in the export and can be linked back to their records |
| Deluge functions, workflow rules, buttons and scheduled jobs | Business rules: pricing, approvals, how orders are handled | You have the code and a plain description of what each one does |
| Zoho Creator apps | Separate apps, often with their own data | Each app's data is exported, along with its forms |
| Sources outside Zoho | XLS spreadsheets, CSV exports, PDFs, database backups, Dropbox folders and raw web pages | Each one is treated as a source to map, the same as Zoho |
Check the last row as carefully as the others. The flooring wholesaler's migration drew on every kind of source listed in it.
Turn scripts and custom fields into stated rules
Before moving any data, describe the business as it should work: customers, products, vendors, orders, purchase orders, invoices and the links between them. For the wholesaler this took a couple of days. Don't copy your old database: design the data model first explains the method.
With the model in place, each customization is read for the need it serves. A custom field either gets one defined meaning in the model or is retired. A script's logic becomes a rule stated in the model, in words a manager can check.
Here is a typical case, simplified for illustration. A Deluge function runs whenever a quote is saved. It compares the quote's discount with an approval limit kept in a custom field on the customer's account. If the discount is higher, it ticks a second custom field so a manager reviews the quote. Nothing on the quote screen says that this rule exists. A field-to-field migration copies both custom fields and loses the rule, because the rule lives in the script.
In the model the rule is written down: a quote needs a manager's approval when its discount is above the customer's approval limit. The approval limit becomes a defined property of the customer, the tick box becomes the quote's approval status, and the script is no longer needed.
Each source keeps its own mapping into the model, separate from the rules that use the data. Intelligence Factory's published case study on integrating dozens of EHR systems applies the same separation at a larger scale: data from nearly three dozen EHR and EMR systems mapped to one internal ontology, with each system's mapping kept apart from the rules for eligibility, billing and reporting.
Import the full history, including closed records
Many migrations move only open orders and active customers, and leave everything else in an export file for reference. The new system then cannot answer questions that depend on the past, such as what a customer has bought or which purchase order filled an order. Staff keep the old system or the export open beside the new one, and the move is never quite finished.
Moving the full history is practical when the import is automated and fast. We build and change CommerceServer with Buffaly, our own software engineering system. For the wholesaler, an automated pipeline imported 15 years of history from Zoho, XLS spreadsheets, CSV exports, PDFs, database backups, Dropbox folders and raw web pages: hundreds of thousands of records, in minutes per run. Because a run takes minutes, the team could compare each result with the source, correct a mapping and run the whole import again. Every correction lives in the pipeline, so it survives the next run. Why your data import should be rerunnable explains why this matters.
Every field brought across was compared with a backup of the old data: 293,986 fields, with zero differences at the end. Reaching zero meant tracing 43 exceptions. For 35 orders the correct date was missing from the old records, so it was recovered from the time the original order email was received. Five products were traced through vendor part numbers, and the remaining three were traced one by one.
Keep Zoho running until the new system has proven itself
Running both systems for a while is the safest cutover, but it usually means double entry. Staff fall behind, and the new system's data stops being trustworthy before it goes live. Running old and new systems side by side without double entry covers the alternative in detail.
For the wholesaler, the parallel run lasted one month. Staff kept working in Zoho and emailed the files Zoho produced, and Buffaly agents entered them in CommerceServer. Every real order tested the new system while Zoho was still in use, and problems were fixed before cutover. The parallel run: staff email files from Zoho and agents enter them describes the setup.
One business, start to finish
How a flooring wholesaler left 15 years of Zoho patches in one month tells the story step by step. What a distributor got by leaving Zoho covers the result: no outside consultant, no Zoho license fees, and a portal where its customers check inventory and submit purchase orders. A sister company moved next. The model already described the business, so its migration was mainly a matter of mapping its own sources, as told in The second migration was the easy one.
Questions to ask before you approve a migration plan
You can put these questions to any vendor or consultant, including the one you have now.
| Ask | A good answer | A warning sign |
|---|---|---|
| Which sources will you import? | Every source on your inventory, including files outside Zoho | Only the Zoho modules |
| How much history moves? | All of it, with records still linked to each other | Open records only, with the rest in an export file |
| What happens to our Deluge scripts and custom fields? | Each one is read and becomes a stated rule or a defined field, or is retired | They are copied or rebuilt as they are |
| How long does one full import take, and can it be rerun from scratch? | Short enough to rerun after every correction | Days, with corrections made by hand afterward |
| How will you prove nothing was lost? | A field-by-field comparison with a backup, plus a list of exceptions | Spot checks |
| How do we run both systems before cutover? | Staff keep working in Zoho while someone else does the entry in the new system | Staff enter everything twice |
Leaving a customized Zoho system?
If your business runs on years of Zoho customizations and a consultant for every change, we can describe your business, change CommerceServer to fit it, move your full history from every source and run both systems until your team is ready to switch. After launch, changes are included in the subscription. Tell us about your current system, or read how full service works.