The problem shows up when things go well
At three orders a day, retyping is bearable. At thirty it isn't, and the bottleneck moves from sales to admin.
The paradox is that the better the store performs, the more manual work it creates. That's usually when people call us.
First decision: which system owns what
This choice determines everything else. For each type of data you must establish which system is authoritative.
Usually the business system owns products, prices and stock; the store owns online orders and registered customers. Exceptions exist and must be decided beforehand, not mid-build.
Second decision: when data travels
Not everything needs to be instant. Stock usually does, because an error there means selling something you don't have. The catalogue can update hourly. Order history can travel overnight.
Syncing everything in real time looks like the better choice, but it costs more and puts needless load on the systems.
Third decision: what happens when something breaks
A system offline, a product with no matching code, a payment on hold: these are normal cases, not emergencies. The design must state in advance whether the operation queues, stops, and who gets notified.
A connection without error handling works perfectly until the first problem, then does more damage than manual work.
Realistic timelines
For a full connection between a store and a business system, tested on real orders, a typical project runs from four to ten weeks. The analysis is short but decisive: nearly every mid-project surprise comes from a special case nobody mentioned at the start.
Frequently asked questions
Our system has no API. Can it still be done?
In most cases yes, through database access or scheduled file exchange. Check with your software supplier first.
Do we have to stop selling during the switch?
No. The connection is tested alongside manual entry and goes live only when the data matches.