Zoho One stops working past ten crores of revenue for manufacturers. Three failure patterns repeat across the firms that bring us in to replace it.
By Mohammad Jamnagarwala · Simply Five Studio
A second-generation manufacturer of industrial hardware in Mumbai walked us through a Zoho One environment that had grown over four years into something nobody at the firm could fully document. Eighteen custom fields on the lead object. Six custom modules. Four different quote templates, one of which had not been updated since the previous fiscal. Two integrations with external tools that had stopped syncing six months ago and that nobody had noticed because the data they produced was not being looked at. The annual subscription was running into seven figures. The founder's question was not "should we move off Zoho". It was "how do we move off Zoho without losing six months to the migration".
This is the conversation we have repeatedly with founder-led manufacturers between ten and fifty crores of revenue. Zoho One is excellent at the entry tier. It stops being excellent somewhere around the point where the firm's operations get sufficiently specific that the generic data model starts to bend in ways the firm cannot fully see.
The first pattern is complex pricing models. A manufacturer's commercial reality involves tier discounts, customer-specific rate cards, quantity breaks, exception pricing for strategic accounts, and conditional discounting tied to material grade or order season. Zoho's price list object handles the first two. The rest get encoded as custom fields, sales rules, or workflow automations that nobody fully audits. Quotes start going out with pricing the founder cannot reconstruct. Margin leaks become invisible.
The second pattern is multi-warehouse operations. Zoho Inventory treats warehouses as containers with simple stock-in and stock-out movements. A real manufacturer's stock movements include transfers between warehouses, allocations against open work orders, rework cycles that move material in and out of WIP, batch tracking for traceability, and bin-location detail that the auditors will ask about. The Zoho object model accommodates some of this through custom fields and notes, but the operational queries the founder needs ("how much 304-grade stainless is currently committed to open jobs across both factories") are not answerable inside the product.
The third pattern is vertical-specific workflows that do not fit Zoho's schema. A cutting-tool manufacturer's sales cycle includes sampling, qualification, and repeat-order workflows that look nothing like a standard B2B opportunity pipeline. A flange manufacturer's RFQ involves drawings, material specifications, and surface-treatment requirements that the Zoho lead object cannot hold without heavy customisation. The customisation works, in the narrow sense that data gets entered, but the resulting object is a Zoho object pretending to be something else. The reporting against it is broken because Zoho's reporting engine does not understand what the custom fields actually mean.
The visible cost of Zoho customisation is the subscription itself, which scales with users and module count. The invisible cost is larger and accumulates over years.
Every customisation is a small piece of institutional knowledge that lives in the Zoho admin's head. When the admin leaves or moves on, the documentation rarely catches up. The next person inherits a system they cannot fully read. The custom fields and workflows continue to operate, but the reasoning behind them is gone.
Every upgrade Zoho ships threatens the customisations. Most upgrades are non-breaking. Some are not. The firm spends engineering attention on regression testing each time, which is engineering attention that could have been spent building.
Every report the founder asks for gets answered with an export to Excel, because the custom-field data does not aggregate cleanly inside Zoho's native reporting. The firm pays for a CRM and uses Excel as the actual reporting layer. The work that the diagnostic for outgrowing Tally describes applies here too. The symptoms are different but the structural problem is identical: the software was sized for an earlier version of the business.
The diagnostic question is straightforward. Open the firm's Zoho admin console and count the number of custom fields on the lead, account, and product objects. Count the active workflow rules. Count the custom modules. Add the number of monthly export-to-Excel steps the team performs to produce founder-facing reports.
If the total exceeds fifty, the firm is past the ceiling. The Zoho instance is not running the business. The business is running the Zoho instance, in the sense that the team's day is shaped by what the system requires rather than by what the firm needs.
The other diagnostic signal is the monthly subscription bill. Once the Zoho One bill (across all seats, all add-ons, and all integrations) crosses the cost of a small engineering retainer, the financial argument for custom flips. The custom system amortises over years. The Zoho subscription does not.
The work for the three-brand cutting-tool group is the case study that founders ask about most often when they are at this threshold. The group was spending lakhs annually on Zoho. The custom system replaced both the subscription and the customisation backlog, and added the multi-tenant architecture that Zoho structurally could not provide.
The fear that founders carry into the custom conversation is that custom means twelve months of build, a team they cannot afford, and a system that will be brittle in production. The fear is informed by horror stories from the previous generation of custom ERP, when the work was done by large consulting firms with quarterly deliverables and minimal continuity.
Custom in the current generation looks different. A four-to-six-month first build is realistic for a mid-market manufacturer. The team is small, often a partnership with a specialised studio. The first build covers the workflows that produce the most operational pain, not every workflow the firm runs. Tally stays in place for accounting. WhatsApp stays in place for some customer communication. The custom system replaces the operational backbone, which is where Zoho was failing, not the entire technology surface.
The work for Amaan Enterprises is structured along these lines. The AI-augmented ERP covers customer management, HR, portal automation, and quotations. The accounting integration is a bridge, not a replacement. The firm did not migrate everything at once. It migrated the workflows where the cost of the previous arrangement was highest, and let the rest stabilise.
The fastest path off Zoho is also the most constrained one. Export the historical data. Land it in the new system as read-only reference. Run the new system in parallel for the first two months with the team double-entering critical records. Cut over once the team is producing equivalent output in the new system without Zoho.
The pattern that wastes six months is the one where the migration team tries to recreate every Zoho customisation in the new system before going live. This produces a custom system that has the same problems Zoho had, because the customisations were the symptom, not the cure. The right move is to rebuild the workflows in their correct shape and migrate the data, not the customisations.
The Zoho ceiling is real, and crossing it is what produces the next decade of operational leverage. The question is not whether to move. It is whether the next system will be a generic SaaS bent again to fit, or a fitted system that grows with the firm, which is the choice the approach page walks through in detail.
If your Zoho instance has more custom fields than your team can document, the conversation begins with a diagnostic of what is actually breaking. Start a Conversation. The first phase maps the workflows that are costing the firm most, and the output is a build plan that fits the firm's commercial reality.
Accounting software produces statutory output. ERP automates the workflows of a generic business. Neither is the same as the structured truth a founder needs to run a specific business. That third thing is decision infrastructure, and it is what founder-led firms eventually outgrow SaaS to acquire.
Every six months a founder asks why they need another system when Tally already runs the books. The honest answer is a diagnostic, not a sales pitch. Here is how to run one on your own business.
Tally is the financial system of record. An ERP is the operational system of record. Most founders buy one and assume it is also the other. The confusion costs years.
The contact form takes about two minutes. The reply comes from the founder within two working days.
