[an error occurred while processing this directive]

This guide is designed for you to use yourself. You have the legal right to your data. This walks you through the exact process: what to ask for, how to ask, what vendors will try, and how to push back. You don't need a lawyer to start this. Try it first. If you get stuck, we can help you work through it.

Your patron records. Your circulation data. Your collection metadata. Your usage statistics. Vendors love it when you forget that's YOUR data, not theirs.

Data lock-in is how they keep you as customers. It\'s not malice - it\'s profit incentive. A library with years of historical data invested in their system is a library that won\'t switch vendors, no matter how much the contract costs or how bad the support gets. They\'ve got you trapped in their database.

But you don\'t have to stay trapped. This guide walks you through extracting your data, negotiating with vendors who\'ll suddenly develop selective amnesia about your rights, and getting out.

About this guide: Everything here is designed for you to execute yourself. The templates work at any library size. Start with Step 1 and follow the process. Most vendors will comply without escalation. If you hit resistance or feel stuck, reach out and we\'ll work through the sticky parts with you. This isn\'t "upgrade to consulting." It\'s "you're doing it, and here's backup when you need it."

Why This Actually Matters

Let me be direct: if you can\'t leave a system, you don\'t own your data. You're renting it.

Vendor lock-in isn't just annoying. It means:

  • Contracts get worse over time. They know you can't leave. Prices go up. Terms shift in their favor. Support gets worse.
  • You can't evaluate competitors. Even if a better system exists, switching costs thousands and takes months because you have to negotiate for your own data.
  • Your innovation is limited. You're stuck with whatever they decide to build. No custom integrations. No flexibility. Their roadmap is your roadmap.
  • If they go out of business, your data might evaporate. Or get sold to a competitor. Or get stuck in legal limbo while bankruptcy happens.
  • You have zero leverage. Problems? Too bad - where are you going to go?

Getting your data out isn\'t just about switching systems. It\'s about having actual power in your vendor relationships.

Before You Ask: Do Your Homework

The worst mistake libraries make is requesting data extraction without knowing what they actually have. Vendors love that. "Sure, here\'s an export" (in a format that\'s useless). Now you've burned your one shot at getting it right.

Pre-Request Inventory Checklist

  • Make a list of every dataset - Patron records, circulation history, item records, acquisitions data, holdings, statistics, configuration, etc.
  • Know the volume - How many patrons? How many items? How many years of circulation data? This matters for timeframe estimates and format.
  • Identify what\'s yours vs. what\'s the vendor's - Vendor-supplied content (like MARC records from their catalog) might have licensing restrictions. Your local metadata is yours.
  • Document what you need vs. what\'s nice-to-have - Patron data is critical. The vendor\'s proprietary analytics? Maybe not worth the fight.
  • Check what\'s already accessible - Some systems give you standard export tools. Use them first to see what\'s easy.
  • Note any custom configurations - Custom fields? Workflows? Business logic? You need to understand what exists so you can demand it.
  • Get /contact.html names and titles - Client success manager, technical /contact.htmls, their legal department. You'll need all of these.

Read Your Contract (For Real This Time)

Your contract probably already gives you the right to your data. Most vendors bury it in section 8.2 or something equally annoying, but it's there.

Here's what to search for:

Key Contract Language

  • Data Ownership - Something like "Licensee retains ownership of all Customer Data." This is your baseline right.
  • Data Portability - "Upon termination, Vendor shall provide Customer with all Customer Data in a machine-readable format." This is what you're going to invoke.
  • Termination Provisions - How long do you have after the contract ends? 30 days? 60 days? This is your timeline.
  • Export Obligations - Does it say they'll provide it in CSV, JSON, standard formats? Or can they pick weird proprietary formats?
  • Data Retention After Termination - What happens to data after you leave? Can they delete it immediately? Keep it? Sell it?
  • Fees for Data Extraction - Some contracts try to charge for exports. Check if there are limits or if you're getting hit with unlimited extraction fees.

Don\'t have a copy? Your director or legal department should have it. If they can\'t find it, the vendor definitely has one. Email them asking for "the current maintenance schedule and data portability provisions." They\'ll send it to you faster than you\'d expect.

Prepare Your Request

This is where most libraries fail. They send a casual email to their support /contact.html asking if they can get their data. Support says "maybe" and disappears for three weeks.

Don't do that.

Your data extraction request needs to be:

  • Specific - Not "all our data," but "patron records (fields: ID, name, email, status), circulation history (fields: item_id, patron_id, checkout_date, due_date, return_date, status) for the period Jan 1, 2018 - Dec 31, 2025"
  • Legal - References your contract and applicable regulations
  • Formal - Sent via certified mail or tracked email with read receipts
  • Timely - Submitted early enough to actually matter (not two weeks before cutover)
  • Documented - You have a paper trail proving you asked

Step 1: Send the Formal Written Request

Data Extraction Request Email Template

Subject: FORMAL DATA EXTRACTION REQUEST - [Library Name] - [System Name] Date: [Today] Reference: Contract dated [contract date], Customer ID: [your ID] Dear [Vendor Name] Legal and Customer Success Teams, This letter serves as a formal request for extraction and delivery of all Customer Data as defined in our service agreement, dated [date], under Section [X.X] regarding Data Portability and Customer Data Rights. REQUEST SCOPE: We are requesting the following datasets in their entirety: 1. Patron Records - Fields: Patron ID, Name, Email, Phone, Address, Patron Type, Status, Registration Date, Last Activity - Format: CSV with headers - Period: All historical records 2. Circulation Records - Fields: Transaction ID, Patron ID, Item ID, Checkout Date, Due Date, Return Date, Item Status, Fines Accrued - Format: CSV with headers - Period: Jan 1, 2020 - Present 3. Item/Holdings Records - Fields: Item ID, Bib ID, Title, Author, ISBN, Call Number, Location, Status, Acquisition Date, Condition Notes - Format: CSV with headers - Period: All records 4. Acquisitions Records - Fields: Order ID, Vendor, Title, Quantity, Cost, Date Ordered, Date Received - Format: CSV with headers - Period: Last 5 years 5. Custom Metadata and Configuration - All custom fields defined in [System Name] - All configured workflows and business logic documentation - All system settings and configuration parameters REQUIRED DELIVERY SPECIFICATIONS: - Format: Standard CSV or JSON (not proprietary formats) - Encoding: UTF-8 - Delimiter: Comma (CSV) or standard JSON structure - Includes column headers and field descriptions - All data must be accompanied by a data dictionary explaining each field - No modification, aggregation, or summarization of data - Complete historical data, not samples or subsets - All data must be current as of [deadline date] LEGAL BASIS: This request is made pursuant to: - Section [X.X] of our Service Agreement dated [date] - Data Portability and Customer Data Rights provisions - [State] Data Protection regulations - Industry standards for data portability (reference NISO standards if applicable) DELIVERY DEADLINE: Please provide this data extraction within 30 calendar days of receipt of this letter. If you anticipate any delays, please notify us in writing within 5 business days explaining the delay and providing a firm delivery date. CONTACT INFORMATION: Primary Contact: [Your name, title, email, phone] Secondary Contact: [Director name, email, phone] Legal/Technical Contact: [If applicable] Please confirm receipt of this request and provide an estimated delivery date within 3 business days. Sincerely, [Your name] [Your title] [Library name] [Date] CC: [Your Director], [Your IT Manager], [Your Library Board/Legal]

Send this via: (1) Certified mail to their legal department, (2) Email with read receipts to your account manager, technical /contact.html, and their general support email. Document everything. If they later claim they never got it, you have proof.

Step 2: Follow Up (They Will Try to Ignore You)

Expect radio silence. Here's the vendor playbook:

Tactic 1: The Slow Disappear

Your /contact.html responds "we\'ll look into it" and then stops replying. After 2 weeks, you follow up. After 3 weeks, your /contact.html is "out of office." After a month, there\'s a new /contact.html who says "I don't have context on this." Repeat forever.

Counter: Set calendar reminders to follow up every 5 business days. Each follow-up goes to the account manager, their manager, and the customer success director. Copy your director. Make it someone's problem to ignore you.

Tactic 2: "Our Technical Team Says It's Hard"

They claim the data extraction is "technically complex" and will take months, or "we don\'t have an automated export for that dataset," or "that data is all mixed with other customers" data so we can't separate it."

Counter: Ask for a written explanation of the technical constraints from their CTO or lead engineer. Ask how long it would take them if you agreed to pay for custom development. Ask if they can export to their internal format and you\'ll hire a contractor to clean it up. Put pressure on them to explain WHY it\'s supposedly hard. 9 out of 10 times it\'s not actually hard - it\'s just low priority.

Tactic 3: "That Data Has Licensing Restrictions"

They claim portions of your data are licensed from third parties (MARC records, classification systems, etc.) so you can't have it.

Counter: This is sometimes legitimate for third-party content, but it's overused. Ask them to separate YOUR data (patron records, circulation, local holdings) from the licensed content. They can provide separately licensed content in accordance with the license terms, but your data is yours. Push back.

Tactic 4: "You Need a Professional Services Engagement"

They say the extraction will cost $50,000 and take 12 weeks because it\'s "custom work." They\'ll send you a SOW for services.

Counter: This violates your data portability rights. Write back: "We appreciate the SOW, but data extraction is a contractual obligation under Section X.X, not optional professional services. We expect standard data exports in standard formats at no additional cost beyond our current agreement." If they push back, this becomes a legal leverage point.

If They Refuse: Escalation Tactics

Sometimes vendors will flatly refuse. They\'ll say no. Here\'s what you do.

Level 1: Internal Escalation (Free, Fast)

They've told their customer success team "no." Go over their head:

  • Email their VP of Sales. Find them on LinkedIn. Their sales rep gets points for renewing your contract. Tell their boss: "We\'re interested in renewing with you, but we need to understand our data rights first. We\'d like to talk to [VP name] about our data extraction request before we commit to another term."
  • Email their VP of Customer Success. Similar play: "We want to be a long-term partner, but we need to trust that we can access our data. Your team has been unresponsive about our formal data extraction request."
  • Involve your state library system or consortium. If you're part of a state system or consortium that negotiated the contract, loop them in. They often have legal leverage that you don\'t.

Level 2: Legal Threat (Cheap Opener)

Have your city/county attorney or your library\'s legal counsel send a letter. It doesn\'t need to be fancy. Something like:

"[Library] has requested data extraction under the data portability provisions of your service agreement. This is a contractual obligation. We expect a response within 10 business days. If the data is not provided, we will pursue all available remedies under contract law, including termination for material breach and recovery of damages."

A legal letter from an actual attorney costs you $300-500 and has a weirdly high success rate. Vendors suddenly remember that data portability is totally doable.

Level 3: Regulatory Angles

Depending on your state and situation, you might have regulatory leverage:

  • State Attorney General\'s Office. If you're in a state with consumer protection laws or data protection regulations, your AG might care about vendor lock-in. File a complaint. It probably goes nowhere fast, but it creates a paper trail.
  • State Library Agency. If you're a public library, your state library agency might have procurement standards or vendor contracts that include data portability requirements. Escalate there.
  • Government Procurement Fraud. If you're a public institution and the vendor is violating contract terms, some states consider this procurement fraud. Your procurement department should care about this.
  • FERPA Violations (Schools Only). If you're a school library and student data is involved, FERPA gives you strong data rights. Vendors know this and will comply faster.

Level 4: Breach of Contract Lawsuit

Actually suing is expensive, but sometimes just the threat works. Talk to your attorney about whether you have a case. Usually you do, if:

  • Your contract explicitly promises data portability
  • They're refusing a reasonable, documented request
  • You\'ve given them reasonable time (30-60 days) and they\'ve said no

A cease-and-desist letter from a real attorney (not a template) costs $1,500-3,000 and has surprising success rates. Vendors have legal compliance people who get very nervous when their company gets a formal legal threat.

What to Expect From the Vendor

Once they actually agree to extract data, here\'s what happens. They\'ll try several things:

Common Vendor Stalling Tactics

What They Say What It Really Means Your Response
"It will take 3-6 months" "We haven\'t started and hope you\'ll forget about it" Ask for a detailed timeline and weekly status updates. If the delay is unreasonable, involve their legal department.
"We'll need to set up a project with professional services" "We want to charge you $50k for something that's a contract obligation" Decline. Reference your contract. Ask for the export from your current support agreement.
"We need more detail on what you want" "We\'re hoping you\'ll give up and ask for less" Say: "We need all Customer Data as defined in Section X of our agreement, in standard CSV/JSON format, with complete documentation."
"We can give it to you, but only in [weird proprietary format]" "We want to make it hard for you to leave" Demand standard formats. Your contract probably specifies this. If not, email: "We need CSV or JSON. If you can only provide proprietary formats, we'll need to escalate this contract compliance issue."
"Some data is under third-party licensing restrictions" "We're mixing your data with content we licensed from others to make it unseparable" Reasonable for third-party content (MARC records, authority files). Ask for YOUR data separated. You'll handle licensed content separately per license terms.
"Your contract doesn't say we have to provide this" "We\'re gambling you don\'t have your contract or understand it" Email back with a specific quote from your contract's data portability clause. Forward it to their legal department.

Realistic Timeline

Here's what actually happens:

  • Week 1: Your request gets to customer success. They say "interesting question."
  • Week 2-3: Internal debate at the vendor. "Can we refuse this? Should we?"
  • Week 4: They agree, but say it will take 12 weeks. You push back.
  • Week 5-6: They escalate to engineering. Engineering says 2 weeks if they prioritize it.
  • Week 7-8: The export actually runs. They send you a test file.
  • Week 9: You find bugs in the export (missing data, corrupt fields, wrong date formats). Back and forth with them.
  • Week 10-12: Final version arrives. Probably still has issues. You accept it because you're exhausted.

That's best case. Sometimes it takes months. The point: start this process at least 90 days before you plan to disconnect.

Converting and Cleaning Vendor Data

You got your data out. It's a mess. Of course it is.

What You'll Get (and Its Problems)

Problem 1: Corrupted Character Encoding

Weird symbols instead of accented characters. Chinese characters show as boxes. Names like "Müller" become "M?ller."

Fix: Most export tools default to the wrong encoding. Ask the vendor for UTF-8. If they give you Latin-1 or something else, convert it with iconv on Mac/Linux or a Python script.

Problem 2: Date Formats

Dates are sometimes in vendor-specific formats (like "43892" which is days since 1900). Or they're text strings in random formats: "01/02/2023" vs "2023-01-02" vs "Jan 2, 2023".

Fix: Standardize everything to ISO 8601 format (YYYY-MM-DD). Use a spreadsheet to convert, or write a Python script if you have thousands of rows.

Problem 3: Incomplete Data

Some fields are blank or missing. Patron emails are all null. Circulation records have item IDs but no item descriptions. Item records are there but missing holdings data.

Fix: Ask the vendor which fields weren\'t exported and why. Sometimes it\'s acceptable (FERPA-restricted fields). Sometimes they just messed up. Get clarification before you accept the export.

Problem 4: Denormalized Structure

Instead of separate tables (items, patrons, transactions), they give you one giant CSV where every patron-transaction combination is a row. Massive file, tons of duplicate data.

Fix: This is annoying but manageable. You can normalize it in a spreadsheet (pivot tables) or write a Python script to split it into proper tables.

Tools That Actually Help

  • OpenRefine (free) - Data cleanup tool. Find and fix encoding errors, standardize date formats, find duplicates. This is your best friend. It looks like old software but it works.
  • Python + pandas (free) - If you have someone who knows Python, pandas can do almost any data transformation. pd.read_csv(), fix stuff, .to_csv(). YouTube tutorials will teach you enough in an afternoon.
  • LibraryBox/Data Migration Services (paid) - Companies like Backstage Library Works and ByWater Solutions specialize in library data migration. They'll clean your vendor export and load it into your new system. $2,000-10,000 depending on data volume.
  • Your New System's Import Tools - Most ILS systems (Koha, Evergreen, etc.) have built-in import tools. They might have sample files showing what format they need. Start with their documentation.

Pre-Disconnection Checklist

Before you actually flip the switch and disconnect from the vendor system, you need to be ready. This is your last chance to catch data quality issues.

Two Weeks Before Disconnection

  • Data validation: Compare patron count in old system vs. exported data. Do the numbers match?
  • Sample checks: Manually verify 20 random patron records in both systems. Do they match?
  • Transaction validation: For a sample week, check that all circulation records exported correctly
  • Foreign character test: Look for any patron names with accents or non-ASCII characters. Are they readable in the export?
  • Perform a test import into your new system with sample data
  • Confirm all stakeholders know the cutover date: IT, circulation desk, management
  • Have a rollback plan if something breaks (you keep vendor system running for 24-48 hours)
  • Document everything: mapping between old and new field names, any custom logic that didn't migrate

Day Before Disconnection

  • Final backup of all vendor system data (encrypted, stored offline)
  • Test full import into new system with complete dataset
  • Document any discrepancies or missing fields discovered during import
  • Notify public: signage about system migration, any outages
  • Brief all staff on new system access and emergency procedures
  • Ensure your IT person and director are available the next day
  • Have backups of backups

Day Of/After Disconnection

  • Run final export from old system (if possible)
  • Update DNS or URL routing to point to new system
  • Perform smoke tests: Can you log in? Can you search? Can you check out a book?
  • Monitor error logs for the first few hours
  • Have staff test core workflows before opening to public
  • Plan to spend first 48 hours in "monitoring mode" with IT on standby
  • Document any issues encountered and how they were resolved

First Week After

  • Run validation reports comparing old vs. new data
  • Ask staff and patrons to report any issues
  • Fix any data quality issues discovered
  • Confirm all historical reports and statistics are accessible in new system
  • Plan formal vendor termination (contract end date may be different)
  • Securely delete old vendor system data (per contract requirements)
  • Document lessons learned for next time

During Disconnection: What Actually Happens

Real talk: migrations usually have problems. Not disasters, usually, but something will be weird. Here\'s what I\'ve seen:

Common Issues on Day One

  • Users can\'t reset passwords. Authentication wasn\'t migrated correctly. Users try to log in, can't remember their password, hit reset, nothing happens. Have a manual password reset procedure ready.
  • Historical reports don\'t work. The new system can\'t read the old system's report definitions. You have to rebuild reports. This is tedious but not a crisis.
  • Item barcodes don\'t scan. Barcode encoding got corrupted during import. You\'ll need to regenerate them. This is bad but fixable overnight.
  • Circulation rules are wrong. Loan periods, fines, holds logic didn't migrate. You have to reconfigure them in the new system. Frustrating but manageable.
  • Custom fields are missing. That special vendor-specific field you were using isn't in the new system. You lose that data. Confirm field mappings in advance to avoid this.
  • Performance is terrible. The new system is slow until it rebuilds indexes. This usually resolves within 24 hours.

Crisis Scenarios (Rare But Real)

  • Data corruption discovered. You notice that patron balances are wrong or item locations are messed up. You have a backup, right? You can restore and try again.
  • Vendor system is still running. New system went live but old system is still responding to queries. Now you have two "current" systems. This is confusing for users. Tell people not to use the old one and shut it down.
  • Integration broke. You have 50 things that connect to the ILS (your website, your email system, your mobile app, third-party services). Some of them don't work with the new system. You have to rebuild those connections.

None of these are dealbreakers. They're all fixable. The point is: expect something to go wrong, have a backup, and have your IT person available.

After Disconnection: Protect Your Independence

You\'ve successfully extracted your data and moved to a new system. Now don\'t let this happen again.

Contract Language for Your Next Vendor

When you negotiate your next contract, add this:

Data Portability Clause (For Your Next Contract)

DATA OWNERSHIP AND PORTABILITY (a) Licensee retains all right, title, and interest in Customer Data. Customer Data means all data, information, and materials provided by Licensee or created through Licensee's use of the Services, including but not limited to patron records, circulation data, holdings information, acquisitions records, and any custom metadata or configurations. (b) Upon termination of this Agreement or at Licensee's request, Vendor shall provide Licensee with a complete export of all Customer Data in the following formats: (i) CSV with standard comma delimiters and UTF-8 encoding (ii) JSON (optional alternative) (iii) All data shall include column headers and field descriptions (iv) Complete data without modification, sampling, or aggregation (c) Data shall be provided within 30 calendar days of termination or request, at no additional cost. (d) For data subject to third-party licensing restrictions (e.g., MARC records, authority files), Vendor shall clearly separate licensed content from Customer Data and provide licensing guidance for Customer's use. (e) Vendor shall provide technical documentation sufficient for Licensee to import the data into any compatible system, including field mappings, data types, and any required transformations. (f) Upon written request prior to the 30-day export period, Vendor shall provide data export in more frequent intervals (e.g., weekly exports) to allow Licensee to validate data integrity. (g) Vendor shall not charge setup, professional services, or other fees for data export compliance.

Ongoing Practices

  • Regular exports. Even if you're not leaving, export your critical data quarterly. This is insurance against vendor failure, corruption, or you discovering new problems.
  • Open standards. When evaluating new systems, prefer systems that use standard data formats (SQL, CSV, JSON) over proprietary databases.
  • API access. Demand API access to your data, even if you don\'t use it now. It\'s leverage if you ever need to integrate or migrate.
  • Document your custom configurations. Keep a separate copy of any custom business logic, workflows, or metadata. Don't rely on the vendor to maintain institutional memory.
  • Open-source when possible. Open-source ILS systems (Koha, Evergreen) give you actual freedom. If the company goes out of business, the system lives on. If they make bad decisions, you can fork it or use a different service provider.

Complete Pre- and Post-Migration Checklist

Before You Ask for Data

  • Document all datasets you need to extract
  • Find your current service agreement and review data portability clauses
  • Get IT involved: understand technical constraints, formats, system architecture
  • Identify your legal /contact.htmls (city attorney, library counsel)
  • Make a spreadsheet of vendor /contact.htmls: account manager, support, legal, executive sponsor
  • Plan your new system: where are you going? What format does it need?
  • Document the business case: why you're leaving, what you're replacing with

Making the Request

  • Send formal written request via certified mail and email with read receipts
  • Request specific datasets with detailed field specifications
  • Specify standard formats (CSV, JSON, not proprietary formats)
  • Include your contract reference and legal basis
  • Request data dictionary and technical documentation
  • Set a reasonable deadline (30-60 days)
  • CC your director and IT manager
  • Keep all communications documented

Handling Delays and Refusals

  • Follow up every 5 business days with escalating recipients (manager, director, VP)
  • If they say it's "technically impossible," request written explanation from their CTO
  • Request weekly status updates and a firm delivery date
  • If refused, escalate to state library agency, procurement department, or attorney
  • Have your attorney send a formal legal letter if necessary
  • Document all refusals and responses

Processing the Export

  • Validate data integrity: count rows, spot-check records, verify data types
  • Check character encoding (should be UTF-8)
  • Fix date formats (standardize to YYYY-MM-DD)
  • Look for corrupted or missing fields
  • Separate any third-party licensed content from your data
  • Test import into new system with sample data first
  • Document any data quality issues and how they were resolved

Pre-Migration (2 Weeks Before)

  • Validate patron count matches between systems
  • Sample-check 20+ random records in both systems
  • Verify all circulation history exported correctly
  • Test full import into new system
  • Document field mapping between old and new systems
  • Brief all staff on cutover plan and new system access
  • Notify public about maintenance window
  • Prepare rollback procedure (keep old system available 48 hours)
  • Have encrypted backups of vendor data

Post-Migration (First Week)

  • Smoke test: login, search, checkout, hold functionality
  • Monitor error logs for issues
  • Run validation reports comparing old vs. new data
  • Have staff and patrons test core workflows
  • Address any data quality issues discovered
  • Rebuild any reports or automations needed
  • Reconfigure circulation rules and policies if needed
  • Update all integrations and external systems
  • Securely delete old system data (per contract)
  • Document lessons learned

Stuck? We're Here to Help

You can do this yourself. Most libraries will. But if you get stuck, you don't have to figure it out alone:

  • Vendor is refusing and you need escalation help. We'll review your contract and write a legal letter that actually works.
  • Your data volume is massive or complex. 5 million patron records? Custom workflows? We can help design the extraction strategy.
  • You\'re lost in the negotiation. Send us the vendor\'s response and we'll help you decide your next move.
  • You need someone to handle the legal escalation. We can send the formal letter vendors actually take seriously.

Stuck? Call us and we\'ll work through it together. You\'re still doing the actual work. We're just helping you navigate the vendor resistance.

Your Next Vendor Conversation

Now that you\'ve escaped vendor lock-in once, you\'ll recognize it when you're evaluating the next system. That demo where everything is on different domains? You\'ll spot it immediately. That vendor who gets cagey when you ask about data export? You\'ll know what\'s happening.

In your next RFP, include this:

"Describe your data ownership and portability policies. Specifically: (1) Who owns the data? (2) In what formats can it be exported? (3) What is the timeline for export upon termination? (4) Are there any fees? (5) Can we export data on demand, or only at contract end?"

If they give you evasive answers, that tells you something. The vendors who make it easy to leave are the ones confident in their product. The ones who make it hard are the ones betting on lock-in.

You know the difference now. Use it.

Questions or your own vendor lock-in horror story? I want to hear it. Get in touch or share in the library tech community. The more we talk about this, the harder it is for vendors to make it a secret.

[an error occurred while processing this directive]