The SAP B1 Add-On Graveyard: What to Check Before You Buy

Welcome to the graveyard

Every SAP Business One consultant has a graveyard. Mine is a mental list of add-ons I've decommissioned over the years -- software that was purchased with enthusiasm, implemented with effort, and then quietly abandoned while still consuming licenses, maintenance fees, and upgrade complexity.

The average B1 system I inherit has two to three of these ghosts. They're licensed. They're installed. Somebody paid for implementation. And nobody has opened them in eighteen months. But they can't just be deleted, because they touched the database, and the next version upgrade has to account for them, and removing them requires a project.

Before you add to the graveyard, run these five checks. Each one takes under an hour. Together, they take a day. The add-ons they filter out would have cost you years.

1. Check the version lag (then verify it yourself)

Ask the vendor directly: "What SAP B1 versions do you currently support, and how quickly do you certify new releases?" Then verify independently -- don't take the brochure's word for it. Check their release notes. Check their support portal. Ask in the SAP B1 community forums.

The graveyard is full of add-ons certified for version 9.3 running on 10.0 systems. They mostly work. Mostly. Until they don't -- usually during month-end close, usually in a way that corrupts data just subtly enough that nobody discovers it for three weeks, usually in the module you needed most.

Version lag is the number one add-on killer I've seen. SAP releases new B1 versions on a regular cadence, and every release changes something -- a DI API behavior, a form rendering detail, a database schema tweak. Add-on vendors who stay current handle these routinely. Vendors who fall behind accumulate a growing gap between what they tested and what you're running.

My rule: if the vendor is more than one feature pack behind the current SAP B1 release, walk away. You're not buying software at that point; you're buying a future upgrade blocker that will hold your entire ERP upgrade hostage until the vendor catches up -- on their timeline, not yours.

I watched a distribution company delay a critical B1 upgrade for eleven months because a single EDI add-on wasn't certified for the new version. Eleven months of missing security patches, missing features, and missing performance improvements -- because of one $8,000 add-on. The upgrade blocker cost them more than the add-on ever delivered.

2. Count the actual users (not the licensed users)

"We have 15 licenses for it" usually means 4 people use it daily, 6 opened it once during training, and 5 have never logged in. Licenses measure purchasing optimism. Usage measures reality.

Before buying anything, identify the specific humans who will use this add-on every single week. Get their actual names. Go talk to them. Ask what problem they're trying to solve and whether this add-on solves it better than what they do today.

I watched a company buy a $12,000 warehouse management add-on because the operations manager saw a great demo at a conference. The warehouse team -- the actual humans who would use it every day -- were never consulted. They took one look at the new workflows, decided they were slower than their spreadsheets, and kept using spreadsheets. The add-on sat licensed, installed, and idle for two years until a version upgrade forced its removal. Total value delivered: zero. Total cost: $12,000 in licenses, $6,000 in implementation, $4,800 in maintenance over two years, plus removal costs.

The demo is not the product. The conference enthusiasm is not user adoption. If you can't name five specific people who are excited to use this every week, you're buying shelfware.

3. Ask who else is using it (and actually call them)

The vendor will happily give you reference customers. Here's the thing most buyers don't do: actually call all of them, and ask the questions that matter.

Ask three specific questions. First: "What broke during implementation?" Every implementation has something -- the honest vendors and customers will tell you what it was and how it got fixed. Second: "What does support actually look like when something goes wrong?" Not the SLA document -- the reality. How fast do they respond? Do they fix it or deflect? Third, and most important: "Would you buy it again?"

That third question is where the truth lives. I've had reference customers pause, sigh audibly, and say "honestly? Probably not." That sigh is worth more than any polished demo. If you can't find three customers who'd repurchase enthusiastically, you're not buying proven software — you're volunteering as a paid beta tester.

Weight the references who have survived two SAP B1 version upgrades with the add-on — they have seen the part that kills add-ons.

4. Test the uninstall (yes, really, before you buy)

Before you sign, ask the vendor: "Show me the complete uninstall process." Then watch their face.

If they look uncomfortable, or if the answer involves phrases like "we'd need to engage our services team" or "it's a bit involved," that's your answer. You're not evaluating a purchase anymore -- you're evaluating a marriage with no prenup.

Add-ons that integrate deeply -- custom database tables, modified system forms, DI API event hooks scattered everywhere, stored procedures -- can be surgically impossible to remove cleanly. I've seen uninstalls that required direct database surgery, custom cleanup scripts, and a full weekend of downtime. I've seen companies keep paying maintenance on dead add-ons purely because removal was deemed too risky.

A well-architected add-on uninstalls cleanly: remove the add-on, the custom objects go away, the system is pristine. A poorly architected one leaves residue in your database forever -- orphaned tables, dead triggers, form customizations that break on upgrade.

You're not just evaluating the purchase. You're evaluating the divorce. And in my experience, the vendors who build clean uninstalls also build better software overall -- it's a proxy for engineering discipline.

5. Price the total cost, not the license fee

The license fee is the smallest number in the real equation — maybe a quarter of what you'll actually spend.

The real math: license fee, plus implementation services (typically 50-100% of license for anything non-trivial), plus training (your people's time has a cost), plus annual maintenance (typically 18-22% of license, every year, forever), plus the internal time your team spends on support, testing, and workaround management, plus -- the one everyone forgets -- the upgrade tax.

The upgrade tax is real and recurring. Every SAP B1 version upgrade now includes testing this add-on, potentially waiting for recertification, and sometimes paying for an add-on upgrade to match. Over five years, that "small" $10,000 add-on typically costs $30,000-40,000 all-in. I've done this math with clients enough times to know the multiplier is remarkably consistent: 3-4x the license fee over five years.

Do the five-year total cost math before you sign. Then do the ROI against the real number, not the license number. If the ROI doesn't survive contact with the true cost, it wasn't ROI -- it was a sales presentation with optimistic assumptions.

The bottom line

SAP Business One's add-on ecosystem is genuinely one of its strengths -- the right add-on, properly vetted, can transform a business process. But the graveyard is full of purchases that skipped these five checks, and every one of them followed the same arc: excitement, implementation, gradual disuse, lingering cost, painful removal.

A day of diligence before buying beats years of regret after. Check the version lag, count the real users, call the references, test the uninstall, and price the true five-year cost. The add-ons that survive all five are the ones worth buying.