Why the number is always too small
Let me be blunt. Implementation partners know the real timeline. They've done this dozens of times. They know your 12-week quote is fantasy. They put it in the proposal anyway.
Why? Because the buying decision usually comes down to two or three partners, and the one with the shortest timeline and the lowest price wins. If Partner A says 12 weeks and Partner B says 22 weeks, Partner A gets the deal even though both of them know it'll take 22. The honest partner loses the bid for telling the truth.
I've watched this play out more times than I can count. The partner isn't necessarily lying to be malicious. Sometimes they genuinely believe this time will be different. Sometimes the salesperson who wrote the proposal isn't the consultant who does the work, and those two people have very different ideas about how long things take. But the effect is the same: you plan your business around a go-live date that was never real.
Then week 10 arrives. You're supposed to be testing. Instead you're still cleaning up item master data because nobody told you that 40% of your SKUs have duplicate entries. The partner says "we need another six weeks." You have no leverage because you're already six figures deep and switching partners now would cost more than finishing late.
What actually takes so long
Here's where the time really goes, based on every SAP B1 project I've been near.
Data migration is always worse than expected. Always. Your QuickBooks file has seven years of creative accounting in it. Your Excel inventory tracker has three different naming conventions for the same product. Your customer list has duplicates, dead accounts, and entries like "Bob, call Dave for details." Cleaning this up takes weeks, and nobody budgets for it honestly because "data cleanup" doesn't sound like something you should pay a consultant $200 an hour to do. But someone has to do it, and it's going to be slow.
Customization creep is inevitable. The proposal says "standard implementation with minor customizations." Then in week three someone asks if the system can do that one weird thing your old system did. The partner says "we can build that." Suddenly you've got three custom add-ons in development and each one needs testing. Every customization adds time in design, build, test, and fix cycles. "Minor" is doing a lot of heavy lifting in that proposal sentence.
Your team isn't available. The implementation plan assumes your warehouse manager can spend 10 hours a week on testing. In reality she's running a warehouse. The plan assumes your controller will validate the chart of accounts by Friday. In reality it's month-end close. Internal resource availability is the silent timeline killer that nobody puts in the risk register because it feels like blaming the customer. But it's real, and it adds weeks.
Training takes longer than the two days in the proposal. You can't train people on a system that's still being configured. Training gets pushed. Then it gets compressed. Then go-live happens and half your team is figuring things out on the fly, which generates support tickets, which the partner bills as "post-go-live support" at full rate.
What a real timeline looks like
For a typical 15 to 30 user SAP Business One implementation with standard modules plus a couple of add-ons, here's what I'd actually plan for.
Discovery and blueprint: 3 to 4 weeks. Not the 1 week in the proposal. Real discovery means someone actually looks at your data, maps your processes, and documents the gaps. Rushing this is how you end up rebuilding things in week 14.
Configuration and development: 8 to 10 weeks. This is the core build. System setup, master data loading, customizations, integrations. This phase always expands because decisions made in discovery turn out to be wrong once people see the system.
Data migration and testing: 4 to 6 weeks. Clean the data, load it, test it, find the problems, fix them, reload. You'll do this at least twice. Budget for three times.
Training and go-live prep: 3 to 4 weeks. Real training, not a two-day workshop. Cutover planning, contingency planning, the unglamorous work that determines whether go-live is boring (good) or exciting (bad).
Total: 18 to 24 weeks. That's the honest number for a standard project. If someone quotes you 12, add 50% and you'll be close.
Protect yourself in the contract
Three things to get in writing before you sign.
First, milestone-based payments, not time-based. Don't pay 50% upfront and 50% at go-live. Tie payments to completed deliverables: blueprint sign-off, configuration complete, data migration validated, user acceptance testing passed. If the partner misses a milestone, you hold the money. That changes the conversation fast.
Second, a rate cap on overruns. Get the partner to agree that hours beyond 120% of the estimate are billed at a discounted rate, or that the total project fee has a ceiling. Partners will push back on this. Push harder. If they're confident in their timeline, they shouldn't fear a cap.
Third, a clear definition of "done." The contract should spell out exactly what constitutes a completed implementation. Which modules, which customizations, what test scenarios must pass, what documentation gets delivered. Vague acceptance criteria are how 20-week projects become 30-week projects with no end in sight.
None of this makes you adversarial. It makes you a serious buyer. Good partners respect it. The ones who squirm are telling you something.
The bottom line
Your implementation partner isn't evil. They're responding to incentives. The sales process rewards the shortest timeline, so that's what goes in the proposal. Your job is to see through it, plan for reality, and protect yourself contractually.
Add 50% to whatever timeline you're quoted. Budget for data cleanup separately. Get milestone payments and a rate cap in writing. And when week 14 arrives and you're behind schedule, you'll be ready for it instead of blindsided by it.
The best ERP implementation is a boring one. Boring comes from honest planning.
About the author: David Strausser is the founder of Dead Brands, LLC, where he helps small and mid-market companies implement Odoo and SAP Business One without the usual consultant nonsense. He's a former Forbes contributor, podcast host, and single dad who has watched enough go-live dates slip to know exactly why it happens.
Ready to talk ERP? Book a meeting with David to get an honest timeline for your SAP Business One project. No fantasy quotes, no surprises.
Wear the brand: Check out the Dead Brands merch store — because surviving an ERP implementation deserves a t-shirt.
