Why history is usually unusable after a migration
It stays behind. Moving history properly is slow, careful work, so it is often the first thing cut from a migration quote. The open orders and the customer list move. The rest goes into an export or a read-only login that nobody opens after a year, and a business that has traded for 15 years can see the last two.
It is split. Orders are in one place, invoices in the accounting software, price agreements and special orders in email, and customer notes in someone's head. Each question below needs at least two of these, so someone exports, pastes and matches by hand.
It is quietly wrong. Missing dates, duplicate customers and products filed under the wrong item make reports worse than no reports, because people believe them. A customer whose history is split across two records looks like two small customers. Cleaning up bad data before it costs you explains how to find and fix these records, and how to move off Zoho without losing your history covers the move itself.
Questions history answers in minutes
Once the history is in one checked model, each of these questions is a lookup, whether the answer comes from a report or from a question asked in plain English. Each one also needs something specific from the data.
Which customers are buying less
Most customers don't leave all at once. They order a little less often, then less again, then stop. The usual report lists customers with no order in 90 days, and it flags the wrong ones. A customer who orders twice a year looks overdue at 90 days and isn't. A customer who has ordered every three weeks for eight years is already a problem at 60. The useful measure is each customer's own usual gap between orders, and how far past it they are now.
This needs every order for each customer, with the real order date, going back far enough to show a pattern.
Which customers are growing and which are shrinking
This year's sales show who is big now. Several years show who is growing, who is shrinking, how much of the business depends on a few customers, and which customers have bought steadily for a decade. This needs one record per customer, with no duplicates splitting a customer's history, and complete order totals by year.
What to buy, and when
One good spring could be a trend or a fluke. Several springs show which. By product line, history shows when demand rises and falls through the year, how consistent that is, and how long suppliers have actually taken to deliver. This needs order lines with real dates and correct products, plus purchase orders with their order and receipt dates.
What actually sells
Sales by style, size, color or line show which lines are declining and which slow sellers are still worth carrying because loyal customers depend on them. This is the answer most damaged by bad product data. When a supplier renumbers a product, its history splits across two records unless someone links them, and each half tells a false story.
This needs every order line linked to the correct product, including history from before the last renumbering.
Where margin went
A price agreed for one large order becomes the customer's standing price, and a discount meant for one season never ends. None of it shows on a single invoice. History shows what each customer actually pays, by product, how that has changed and how it compares with list price and with similar customers. This needs order lines with the price actually charged, linked to the right customer and product, over several years.
What happened on that order
When a customer disputes an invoice from two years ago, you need the order, its changes, the purchase order that filled it, the invoice and the payment together. If those live in three systems and an inbox, a ten-minute answer takes half a day. This needs orders, purchase orders and invoices moved with the links between them intact.
What shape the data has to be in
| Question | What the data needs |
|---|---|
| Who is buying less | Every order per customer, with real order dates |
| Who is growing or shrinking | One record per customer, complete totals by year |
| What to buy, and when | Order lines with real dates; purchase orders with order and receipt dates |
| What actually sells | Every order line linked to the correct product, across renumbering |
| Where margin went | The price actually charged, by customer and product, over years |
| What happened on that order | Orders, purchase orders and invoices with their links intact |
That comes down to four conditions. All of the history is in one model, including the older years. The records are linked: orders to customers, products, purchase orders and invoices. Dates and products are correct. And the moved data has been checked against the original, with anything that can't be proven labeled as such.
For the flooring wholesaler that left Zoho, this was the core of the work. An automated pipeline imported 15 years of records, hundreds of thousands of them, in minutes, into one model of the business. Every field brought across was compared with a backup of the old data: 293,986 fields, with zero differences after 43 exceptions were traced back to source documents. Thirty-five of those were order dates missing from the old records. Each was recovered from the time the original order email was received, which is the date the buying-less question depends on. Five were products, traced through vendor part numbers. Invoices that could not be proven against a source document were kept and labeled as historical source invoices, so only proven records are presented as verified. How a flooring wholesaler left 15 years of Zoho patches in one month tells the full story, and why your data import should be rerunnable explains how the import was run again after every correction.
With the history in one place, the business 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.
The sources don't stay the same, either. We build and change CommerceServer with Buffaly, our own software engineering system. When a file arrives in a layout the agents have not seen, Buffaly writes a new reader for it and uses it in the same session. We consider this key to how Buffaly works. In Buffaly Builds Its Own Tools, an analysis of 1.2 million messages and over 380,000 tool calls from a real Buffaly instance found that 70% of newly created tools were used in the same session they were written.
Example questions from a flooring distributor
Flooring adds its own detail. A product is a style and color in a vendor's line. An inventory piece is a specific roll or cut of that product in a warehouse. With both in the model, along with vendors, purchase orders and customers, a flooring distributor can ask questions like these. They are examples of the kind of question, not a list of any one business's reports.
- Which dealers bought less of a style this year than last, and which style did they buy instead?
- Which styles and colors sell in spring and which in fall, across every year on record?
- Which roll ends and cuts have sat in the warehouse longest, and which customers usually buy that style?
- Which vendors' purchase orders usually arrive late, and by how much?
- Which customers pay below the usual price for a line, and since when?
- When a vendor renumbered a style, did its sales really fall, or did they move to the new number?
What a flooring distributor's data model looks like shows the model these questions run on.
Where to start
If your history is already in one place, start with three reports. Run a weekly list of customers past their own usual gap and call the top ten. Compare the price paid by customer and product over time, and find the customers paying well below similar customers. Use sales by line, by month, for every year you have, in your next round of buying.
If your history isn't in one place, getting it there and checking it comes first. Every report above depends on that, and none of them can make up for it afterwards. The business data migration checklist sets out the checks to ask for.
Tell us which questions you can't answer today
CommerceServer is built, run and continually improved by one accountable team, with the improvement capacity agreed for each engagement. Tell us which of these questions takes a spreadsheet and a weekend today, and where your history lives. We will tell you what it would take to answer them from one model of your business. Tell us about your current system, or read how full service works.