What staying on Zoho was costing
Zoho is capable software, and it can be customized a long way. The wholesaler's problem was who did the customizing and what it cost to keep going.
- Consultant time. Every new need became a request to an outside consultant and, eventually, an invoice. After 15 years the consultant was the only person who fully understood how the customizations fit together, so every change depended on one outside person.
- License fees. The business paid Zoho for the platform and paid the consultant to make the platform fit.
- Missing features. Some things the business needed were not in its Zoho system.
The data had also spread out. Records lived in Zoho, XLS spreadsheets, CSV exports, PDFs, database backups, Dropbox folders and raw web pages, so answering a question about one customer or product could mean checking several places.
More features, built on one model of the business
Every feature and report the wholesaler asked for was built.
The wholesaler now runs its own custom workflow, custom business rules and custom reporting, all supported in CommerceServer. It never had that in 15 years on Zoho.
Adding features was practical because of the order of the work. Before any data moved, we described the business as a data model, called an ontology: customers, products, inventory pieces, vendors, orders, purchase orders and invoices, and the links between them. Then we changed the CommerceServer schema to fit that model. Don't copy your old database: design the data model first explains the method.
A feature built on that model reads data that already has one clear meaning. Take a question every distributor asks: which purchase order filled which customer order? In a system patched for 15 years, the answer may sit in a custom field someone fills in by hand, or in a note. In the model it is a defined link between the two orders. A report that needs the answer reads the link, and so does a new screen. Nothing has to be rebuilt on top of a workaround.
How changes are made without a consultant
Changes now go to the team that built the system. We build and change CommerceServer with Buffaly, our own software engineering system. The business says what it needs, and the change is made to the model and the software, tested and released. With CommerceServer, changes are part of the monthly subscription, so a new need does not start a scoping project or a change order.
Two things make this work without a consultant.
First, the business rules that used to sit in Zoho scripts and custom fields are now stated in the data model. Whoever makes the next change can see what the system does and why, instead of working backward from a script.
Second, Buffaly makes engineering work fast enough to include in a subscription, and it builds the tools it needs as it goes. In Buffaly Builds Its Own Tools, an analysis of 1.2 million messages and over 380,000 tool calls found that 70% of newly created tools were used in the same session they were written. That is how this wholesaler's parallel run handled new file layouts: when a Zoho file arrived in a layout the agents had not seen, Buffaly wrote a tool for it and used it right away. The parallel run: staff email files from Zoho and agents enter them has the details.
A worked example: one request, handled two ways
The request is the one behind this wholesaler's portal: let business customers check stock and send purchase orders online. The Zoho column describes the usual route for a heavily customized Zoho system. It is not a quote the wholesaler received.
| Step | Customized Zoho with a consultant | CommerceServer |
|---|---|---|
| Who you ask | The consultant | The team that built your system |
| What happens next | A scope, an estimate and approval of the cost | The change is built, tested and released |
| Where the portal's data comes from | Zoho's portal features or a separate app, set up and connected by the consultant | The same CommerceServer data the staff use |
| What it costs | Consultant hours, plus any Zoho edition or add-on the portal needs | Included in the subscription |
| Who fixes it when something changes | The consultant, billed again | The same team |
Zoho can do this. What differs is who does the work, how each change is paid for and whether the portal sits on the same data as the rest of the business.
One subscription instead of Zoho licenses plus consultant bills
When the business stopped using Zoho, it stopped paying for Zoho. CommerceServer is paid monthly, the same way Zoho is, and changes are included in that subscription. Instead of a license for a general product plus a consultant to make it fit, a CommerceServer customer pays one subscription for a system built around its business.
A portal where customers check inventory and submit purchase orders
The largest new piece was a B2B web portal. The wholesaler's business customers log in, check inventory and submit purchase orders themselves.
The portal runs on the same CommerceServer data the staff use. Nothing is copied or synced between systems, so the stock a customer sees is the stock recorded in CommerceServer, and a submitted purchase order arrives in the system the staff already work in. From there it is handled like any other order. One B2B job from quote to purchase order follows a job in CommerceServer through the sales order, the invoice and the supplier purchase orders.
A B2B ordering portal for distributors covers what any portal needs from the data underneath it, and why portals built on a separate copy of the data tend to fail.
How long the move took
One month, and most of that month was a parallel run. Describing the business as a data model took a couple of days. An automated pipeline then imported 15 years of history from Zoho, XLS spreadsheets, CSV exports, PDFs, database backups, Dropbox folders and even raw web pages: hundreds of thousands of records, in minutes per run. All 293,986 fields brought across matched a backup of the old data, once 43 exceptions had been traced, mostly through email timestamps and vendor part numbers. During the parallel run, staff kept working in Zoho and emailed the files Zoho produced, and Buffaly agents entered them in CommerceServer, so every real order tested the new system before cutover.
A sister company started its own migration right away. If you are planning the same move, Moving off Zoho without losing your history covers what to export from Zoho and where its data hides.
Add up what staying on your current system costs
You can put numbers on staying before you talk to anyone. Gather these for the last 12 months:
| What to add up | Where to find it |
|---|---|
| Your Zoho subscription, or your current platform's | Your Zoho invoices or billing page |
| Consultant and developer invoices | Accounts payable |
| Add-on apps and connectors billed separately | Card statements and app billing pages |
| Requests still waiting on the consultant, and how long each has waited | Your consultant's ticket list or email |
| Staff hours spent re-typing data between systems or keeping side spreadsheets | Ask the people who do it, then multiply one week by 52 |
| Things customers ask for that you cannot offer, such as checking stock online | Sales and customer service |
The first three rows are what staying costs in cash. The last three are what it costs in time and missed sales. If the waiting list is long, or the same requests keep coming back, the problem is the way changes get made, and a higher plan or another add-on will not fix it.
Paying a consultant every time your system has to change?
If your business runs on a customized Zoho system and every change goes through a consultant, we can describe your business, build CommerceServer around it, move your full history and run both systems until your team is ready to switch. After launch, changes go to the team that built it. Tell us about your current system, or read how full service works.