All summer we were moving the locations of the SneakNFresh network from the previous CRM to our own. On paper the task sounds simple: export orders, clients and history from one system and import them into another. In practice almost all the time went not on the move but on checking.
We decided to say honestly what went wrong. Not because it is a rare case, but because for anyone who is going to move data from one system to another, these are exactly the three places that need the closest attention.
the discount was calculated on something other than we thought
In the previous CRM a discount on an order was stored and applied at the level of a single unit, not of the order item. The difference sounds like a technical detail, but it changes the final amount. If an order has three units of one service and the discount is calculated as a percentage of one unit rather than of the item's amount, the amount diverges on recalculation. We didn't catch it right away: the first checks showed matching figures where the order had one unit, and diverged where there were several.
When the difference was found, we had to rewrite the discount import logic separately for items with several units and check them manually for each location, rather than trusting the summary totals from the export.
the location's time zone never made the move
Every location in the network has its own time zone. This is not an abstraction but part of the data: it determines which day an order belongs to. The previous CRM didn't pass the location's time zone in the export, so all orders arrived with a time not tied to a place. We took the server time by default — and the daily reporting at non-Moscow locations immediately went off: orders closed late in the evening local time landed in the next day's report, and the other way around.
We fixed it only when we set up an explicit time-zone link for each location already at the directories stage — before moving the orders themselves. The lesson is simple: a time zone is not a service note but part of an order, and it has to be moved before the money, not after.
Now the locations' time zones live in the shared directory of ID.Knopka — with locations, cities, time zones and currencies. All products take it from there, so the time zone is set once rather than separately in each system.
performers on services arrived from thirteen locations at once
In the previous CRM the list of performers for a service was not strictly tied to one location. When we exported the service directory, each service pulled in performers from thirteen locations of the network at once, not only from the one the service belongs to. If we had imported this as it was, an administrator would have seen in a service card technicians from cities where that location has never operated.
We had to untangle this link by hand: match each performer to the location where they really work, and only then move the “service — performer” link. There was no automatic export for this step — only a manual check of the list for each location.
what we do differently now
The main conclusion: moving data from someone else's system is not a technical “export and import” operation but a full analysis of how someone else's data is built. Before moving even one order, you need to understand: at what level the discount is calculated, whether the time zone is tied to the location and how the links that look different in the new system are built.
Now we start the move of each location not with the export but with a check of a control group of orders — by hand, every number — and only then move everything else. This is slower at the start. But it is the only way not to find out about a discrepancy in discounts after the partner has already started working with the new numbers.
how it turned out
Since the end of June 2026 CRM.Knopka has been working on the SneakNFresh network every day, together with the migrated order history. Today that is 712,321 orders since 2021, 175,834 clients and 70+ locations in 6 countries — across the SneakNFresh network, including locations that keep their records outside the CRM.
What happens to an order after the migration — from intake to pickup, with performers and statuses for each item — was covered in the article CRM for a shoe cleaning network: how an order works from intake to pickup.
frequently asked questions
why can't I just export the data and import it into the new CRM?
Because systems are built differently inside. A discount may be calculated on a different unit, a location's time zone may not be exported at all, and the links between services, technicians and locations may be different. Without a check, amounts and dates will diverge.
what should I check before moving orders?
Three things: at what level the discount is calculated (a unit or an item), whether the time zone is tied to the location and which locations the performers actually belong to. And start with a manual check of a control group of orders.
why do I need a location's time zone if the order time is already there?
The time zone determines which day an order belongs to. Without it, orders closed late in the evening local time land in the next day's report, and the daily reporting doesn't add up.
is the order history migrated?
In the SneakNFresh network the order history has been migrated since 2021 and works in CRM.Knopka together with new orders.
where does Knopka store a location's time zone?
In the shared ID.Knopka directory — together with locations, cities and currencies. All products take it from there: CRM, ERP and LMS.
