Use case · Measured May 23 to June 29, 2026
How long it really takes to connect your ERP
The honest answer: what takes time is almost never the technical part. Here's the actual timeline of an integration, measured day by day on a system that runs in production today, and what happens in each stretch.
This is a real-world use case, and it's not the only thing we do. The days below aren't an estimate: they come from the project's history, milestone by milestone. We chose to share this because it's the question people ask most and the one that gets answered worst, but the method is the same for payments, inventory, purchasing, or any other process that leaves data behind.
The timeline, with dates
An eight-store chain with its ERP split across several databases, one per store. Work started on May 23, 2026, and these are the dates of each milestone, with elapsed days in parentheses:
- May 27 (day 4): the first record copied from the ERP into the data warehouse.
- June 11 (day 19): that copy verified against the source system and reconciling to the cent.
- June 21 (day 29): the first recommendation produced by the system.
- June 25 (day 33): recommendations starting to reach the decision-maker's phone.
- June 29 (day 37): the start of the operating window we later measured.
Copying the data took four days. Being able to trust it took fifteen more. That ratio is what almost nobody tells you.
Since that last date, the system has run every night without interruption. As of this writing it has been in production for three months, and the numbers we publish came from there.
What happens in each stretch
Days 0 to 4: the connection
This is the technical part, and it's the shortest. You set up the read-only user, open the path to the replica, and copy the first batch of tables.
Here the clock isn't run by whoever writes the code. It's run by whoever grants access. If the person who grants access is the same person who makes the call, this takes days. If you have to wait on an outside vendor who manages the server, it can take weeks, and nothing on the technical side will speed it up.
Days 4 to 19: proving the copy tells the truth
This is the stretch that surprises people, and the one that separates serious work from a demo. Having the data copied doesn't mean it's right: you have to prove that what the warehouse says matches what the ERP says, down to the last cent, for every store.
That's where the real differences in any multi-database operation show up: codes each store enters differently, dates recorded under different rules, transactions logged late. Each one has to be understood before moving on, because a metric built on data that doesn't reconcile produces numbers that look good and aren't.
Skip this stretch and the system still launches and shows dashboards. The problem shows up two months later, when someone checks a number against the ERP, it doesn't match, and from then on nobody believes it again.
Days 19 to 29: from data to a decision
Once the data is reliable, the metrics get built, and only then does the first recommendation appear: not "here's an odd number" but "move these units from this store to that one." The gap between those two is half the work.
Days 29 to 37: getting it to where decisions are made
The recommendation has to leave the system and show up where the person already is, with the answer one tap away. It's not much work, and it's the stretch that most decides whether this gets used or abandoned.
What actually slows things down
Access. It's the first thing to request and the hardest to get when a third party manages the server. It's worth starting there, even before anything is signed.
The quality of historical data. If the system keeps daily inventory snapshots, the work starts with history. If that history has to be rebuilt, you lose time, and the series you end up with is an inference.
How many databases there are. An operation with a single database is noticeably faster than one with a database per store, because aligning rules across databases is most of the verification stretch.
Who answers the questions. There are always questions only an insider can answer. If there's a designated person, they get resolved the same day. If you have to chase someone busy, each question costs a week.
Why we don't promise a timeline
The days above come from one case, not a guarantee. That case had several databases (which adds work), and also fast access and someone answering questions the same day (which speeds it up). Another company could take half as long or twice as long, for reasons you only learn once you look at its data.
What we can say is the shape of the curve: the connection is fast, verification is what takes time, and the value shows up when the first recommendation reaches the person who decides. A vendor who promises you everything up and running in a week is skipping the middle stretch, which is exactly the one that makes the numbers trustworthy.
Want to know how long it would take for you?
On a 20-minute call, we look at how many databases you have, who manages the server, and how much history your system keeps. That's enough for a real estimate, which is different from a promise. Free, and no sales pitch.
And if this isn't your problem, the call is still worth it: we do the same work on payments, inventory, purchasing, or any process that leaves data behind.
The measured results of what that system found once it was running are on the home page.