Your "All-in-One" Vendor is 200 HTML Files in a Trench Coat

Let me tell you about a demo I sat through last year.

The vendor was showing off their "integrated library platform." Seamless workflows. Everything in one place. The future of library technology.

Then I asked to see the URL bar.

As the sales rep clicked through the demo, I watched the URLs change. catalog.vendorname.com became analytics.differentdomain.com became app.thirdcompany.io. Three different domains. Three different visual designs. Three different login systems hidden behind a single sign-on wrapper.

The "integrated platform" was three acquired companies duct-taped together with SSO and a consistent top navigation bar.

I\'ve seen this pattern dozens of times. And I\'m going to teach you how to spot it before you sign a five-year contract.

How "All-in-One" Platforms Actually Get Built

Here\'s what vendors won\'t tell you during the sales process: most "integrated" library platforms aren\'t built. They\'re assembled.

The typical pattern goes like this:

1. A company builds one thing well. Maybe it\'s an ILS. Maybe it\'s a discovery layer. Maybe it's analytics. They get good at that one thing.
2. Private equity notices. The company gets acquired. Now there's pressure to grow revenue faster than organic growth allows.
3. They start buying competitors and adjacent products. Need analytics? Buy an analytics company. Need a discovery layer? Acquire one. Need interlibrary loan? Purchase that too.
4. They slap a unified interface on top. Single sign-on. Consistent branding. Maybe a dashboard that links to everything.
5. They call it "integrated" and charge a premium.

The problem? Under the hood, you still have five different products built by five different teams on five different technology stacks with five different data models.

The Real Cost of Frankenstein Software

Why does this matter? Because integration theater has real consequences for your library.

Data Doesn't Actually Flow

When a vendor acquires a product, they inherit its database schema. Patron records in the ILS don\'t automatically sync with patron records in the analytics module. Usage data from discovery doesn\'t seamlessly connect to collection development tools.

So you end up with:

• Manual data exports and imports between "integrated" modules
• Patron information that doesn't match across systems
• Reports that require pulling data from three different places and reconciling it in Excel
• Duplicate records because the systems can't agree on what a "patron" or "item" actually is

I\'ve seen libraries spend 10+ hours a week on data reconciliation tasks that shouldn\'t exist in an actually integrated system.

Updates Break Things

When you have five acquired products pretending to be one platform, updates get complicated.

The analytics team ships a new feature. It breaks the connection to the ILS because nobody told them the ILS team changed an API endpoint last month. Now your circulation stats aren\'t updating, and support is bouncing you between three different teams who all say it\'s someone else's problem.

I watched one library go six weeks without working analytics because two internal vendor teams couldn't agree on whose bug it was.

Support Becomes a Maze

You call support with an ILS problem. They transfer you to the ILS team. The ILS team says it\'s actually a discovery issue. Discovery says it\'s a data integration issue. Integration says it's an ILS configuration issue. Back to square one.

This isn\'t incompetence. It\'s the inevitable result of bolting together products that were never designed to work together. The support staff genuinely don't understand the other modules because they were separate companies six months ago.

You're Locked In Harder

Here's the sneaky part: the more "integrated" your vendor claims to be, the harder it is to leave.

When you had separate vendors for ILS and discovery, you could swap out discovery without touching your ILS. Now everything's bundled. Want to switch analytics providers? Good luck extracting your data from a system that was designed to keep everything in one proprietary silo.

That\'s not a bug. That\'s the business model.

How to Spot a Trench Coat Vendor

Before your next vendor demo, here's what to look for:

1. Watch the URLs

Ask to see the address bar during the demo. Click through every module. If the domain changes, you're looking at separate products.

Red flags:

• Different subdomains for different features (analytics.vendor.com vs catalog.vendor.com)
• Completely different domains (especially if they include the name of an acquired company)
• The URL structure changes completely between modules

2. Ask About the Tech Stack

During the demo, ask: "Is this all built on the same technology, or are some modules on different platforms?"

Honest vendors will tell you. Evasive vendors will say things like "We use best-of-breed technologies" or "Our architecture is flexible." Translation: different products, different stacks.

Specific questions to ask:

• "Is patron data stored in one database or multiple databases?"
• "When I update a patron record in the ILS, how long until it's reflected in analytics?"
• "Are all modules built by the same development team?"

3. Check the Acquisition History

Before the demo, do 15 minutes of research. Search for "[vendor name] acquisition" and "[vendor name] acquires."

Make a list of every company they've bought. Then, during the demo, ask about each product by its original name. "Is your analytics module the same as [acquired company name]?"

If they\'ve acquired five companies in the last three years, they\'ve been assembling, not building.

4. Test the Data Flow

Ask for a trial or sandbox environment. Then test whether data actually moves between modules.

• Create a patron record. Does it appear in all modules immediately?
• Check out a book. Does the transaction show up in analytics in real-time?
• Update a bibliographic record. Does the change propagate everywhere?

If there\'s a delay - especially if it\'s measured in hours or days - you're looking at systems that don\'t actually talk to each other. They're doing batch synchronization, which is code for "we move data around overnight and hope nothing breaks."

5. Ask About the Roadmap

"When do you expect [Module A] and [Module B] to share a unified codebase?"

If the answer is vague or years away, the integration is cosmetic and likely to stay that way. True integration is expensive and slow. Most acquired products never get fully integrated - they just get maintained until they're eventually sunset.

The Questions They Don't Want You to Ask

Here's a cheat sheet for your next vendor meeting:

"Which parts of your platform were built in-house vs. acquired?"

They have to answer this. It\'s public information. But they don\'t want to volunteer it because it undermines the "unified platform" narrative.

"If I want to leave, can I export my data from each module separately?"

This exposes whether the modules are actually separate systems. If they have different export processes, they're different products.

"When there's a bug that spans multiple modules, who owns it?"

If they hesitate or say "it depends," you're going to spend a lot of time being bounced between support queues.

"Can I buy just the ILS without the discovery layer?"

If everything is truly integrated, this should be a weird question. If they say yes, or if they suddenly offer a discount to take the bundle, the "integration" is a sales tactic, not an architecture.

"How many different teams worked on this demo?"

In a genuinely integrated product, it might be one team or two. In an assembled product, the answer is often "several" or they'll dodge the question entirely.

When "Integrated" Is Actually Good

I'm not saying all bundled products are bad. Sometimes an acquisition leads to genuine integration over time. And sometimes a unified vendor relationship is simpler than managing five separate contracts.

Here's when the trench coat might be worth wearing:

• You're a small library with limited IT capacity. One vendor, one support number, one contract. Even if the integration is cosmetic, the simplicity has value.
• The acquisition happened 5+ years ago. That\'s enough time for real integration work to happen. Ask for specifics about what they\'ve unified.
• You\'ve talked to references who\'ve been on the platform for years. Not new customers. Long-term customers who've lived through the integration process and can tell you if it actually works.
• They\'re transparent about what\'s integrated and what isn\'t. Honest vendors will tell you "our analytics module runs on a separate system, and here\'s how we handle data sync." That honesty is worth something.

What This Means for Your Next Decision

The library technology market is consolidating fast. Ex Libris bought by Clarivate in a $5.3 billion deal. Innovative acquired by ProQuest. EBSCO buying up everything adjacent to database content. (For the deep dive on what this consolidation means, see The Scholarly Kitchen\'s analysis and the Code4Lib Journal\'s "Managing Electronic Resources Without Buying into the Library Vendor Singularity".)

This means almost every major vendor is now selling acquired products under unified branding. The question isn\'t whether you\'ll deal with a trench coat vendor - it\'s whether you\'ll understand what you're actually buying.

So before you sign:

1. Research the acquisition history. Know what you're buying and where it came from.
2. Test the integration claims. Don't take "seamless" at face value. Make them prove it.
3. Negotiate as if the modules are separate. Because they probably are. Get separate SLAs, separate data export rights, and separate termination clauses for each major component.
4. Plan for the reality, not the sales pitch. Budget staff time for the data reconciliation and support escalations that will inevitably happen.

The vendors aren\'t lying when they call it integrated. They\'re just using a very generous definition of the word.

Your job is to look under the trench coat.