Vendor Migration Playbook

I know the pitch vendors give you: "Quick migration. Minimal downtime. We've done this a thousand times."

That\'s marketing. The reality is different. And here\'s the thing: you can navigate this if you know what to expect.

A vendor system migration is 6-12 months of your life. It\'s staff working nights and weekends validating data. It\'s patrons confused about why systems changed. It\'s budget overruns and timeline slips. It\'s the thing that looked simple in the proposal suddenly having seventeen hidden complexities.

I watched a 45,000-patron library migrate ILS systems. They promised "minimal disruption." Fourteen months later, they were still cleaning up data problems. Staff was burned out. Patrons were frustrated. The library learned what I'm about to tell you: migrations are not quick, and you need to plan for that.

Here's what a migration actually looks like.

What You're Actually Trying to Move: The Data Reality

Before you understand the timeline, understand what you're moving. It\'s more complex than it sounds.

Bibliographic Records

These are the books you have. MARC format (Machine Readable Cataloging). If you have a 45,000-patron library with 500,000 items in your collection, you have roughly 300,000-400,000 bibliographic records (multiple copies of same title = one record).

Sounds simple. It's not. Each record has:

• Standard fields (title, author, ISBN)
• Local customizations (your specific item types, your specific fields)
• Vendor-specific extensions (stuff your current vendor added that nobody else uses)
• Custom data that's been accumulated over 15 years

When you move to a new system, all that custom stuff needs to either (a) map to new vendor's equivalent, or (b) be stripped out, or (c) be manually fixed. This is weeks of work.

Holdings Records

For each bibliographic record, you have holdings (which library branches have which copies, in what condition, with what restrictions). For a 45K-patron system with 500,000 items, you might have 450,000+ holdings records.

These need to migrate perfectly or patron searches show wrong results.

Patron Records

45,000 active patrons. Each has:

• Contact information
• Checkout history (for some vendors, this is exportable; for others, it's lost)
• Holds queue
• Fine/fee history
• Patron type and permissions
• PIN or password (usually hashed, so you have to reset on migration)

New system might have different patron type definitions. New system might not support historical holds or fine data. You need to decide: do you keep this data and adapt it, or do you start fresh and lose history?

Circulation/Transaction History

Years of "patron X checked out book Y on date Z" information. This is often vendor-proprietary and hard to export. Many migrations lose this data entirely.

Can you export it? Maybe. Will it be usable in the new system? Probably not. Will anyone actually care 3 years after the migration? Probably not. But your archivist might.

Custom Configuration Data

Your current vendor has probably let you customize things:

• Circulation policies by patron type and item type
• Fine calculation rules
• Custom item statuses ("Bindery," "Preservation," etc.)
• Reports you've built
• Interface customizations
• Integrations with other systems

New system will have different ways of doing all this. You need to audit what you have, figure out what's important, and rebuild in the new system.

Phase 1: Planning (Months 1-2) - How To Start

Timeline: 6-8 weeks before you can even start technical work.

This is where you establish control. You can\'t manage what you don\'t plan. These early decisions determine whether you control the migration or it controls you.

What Happens (And What You Do)

• Board approves migration plan. You provide the plan. See "The Playbook Checklist" below for what goes in it.
• Hiring decisions: Ask yourself: Do you have 1.0 FTE available for 6 months? No? Budget contractors ($15-30K). This is non-negotiable.
• New vendor confirms project schedule. Don't accept their estimate. Use Phase 2-7 timelines in this article to push back if they say "90 days total."
• Decision on go-live date. Pick 6-9 months out. Earlier is false economy. Later is waste.
• Organizational kickoff meeting. You run this. Set expectations now: this will be disruptive, and that's normal.

The Gotchas

• Consensus doesn't exist yet. Your public services librarian wants to keep patron history. Your IT director wants to start fresh. Your director wants minimal cost. You need to decide before technical work starts.
• You haven\'t actually audited your data. You don\'t know if your data is clean enough to migrate. This phase should include a preliminary data quality assessment.
• Scope creep starts immediately. Someone suggests "while we\'re migrating, let\'s also implement new circulation policies" or "let\'s integrate with our city\'s permit system." Say no. Migrations are not the time to add features.

Key Decisions

Make these in phase 1 or regret them forever:

• Parallel running? Run old and new system simultaneously for a testing period? (Costs more but safer.)
• Downtime? How many hours/days of patron-facing downtime is acceptable during cutover?
• Data cleansing? Clean current data before migration, or clean it after? (Before is better but costs time.)
• Custom features? What current customizations must move to new system vs. what are we willing to lose?

Timeline Estimate

6-8 weeks minimum. Longer if you have staff turnover or need board approval cycles.

Phase 2: Data Extraction & Analysis (Months 2-4)

Timeline: 6-12 weeks.

This is where the real work starts. You're learning what data you actually have.

Data Extraction

• Request data extract from current vendor: MARC records, patron records, transaction history, configuration. Most vendors have standard export processes, but some will charge extra for "custom" extracts.
• Receive unfinished export: Your vendor's export is incomplete or in wrong format. You need technical staff to validate it.
• Identify what's missing: Some data types might not be exportable. You decide: does it matter?
• Clean the data: Deduplicate patron records. Fix character encoding issues. Fix MARC field problems. Remove test data from years ago.

Mapping Exercise

Sit down with new vendor and current data. Create a mapping document:

• "Current patron type "Adult" maps to new system\'s "General Adult'"
• "Current item type "Book" maps to new system\'s "Monograph'"
• "Current fine rule "Adult standard" needs to be recreated as custom rule in new system"

This document becomes your reference for the whole migration. Get it right or spend months fixing data problems post-migration.

The Gotchas

• Patron records have no standard format. Your current vendor stores patron info differently than the new one. Merging duplicates is harder than you think.
• Historical data doesn\'t migrate cleanly. If your vendor stored checkout history in vendor-specific format, it probably can\'t move to new system.
• Custom fields might be lost. You have a local field "preservation note" that your staff uses daily. New system doesn't have an equivalent. You lose it or rebuild manually.
• Character encoding issues. Data entered in 2005 with different character set causes corruption. Time to clean it manually.
• Vendor delays the data extract. You asked for it in month 2. Vendor doesn\'t provide it until month 3.5. Now you're behind on your timeline.

Staffing Reality

You need:

• IT staff to extract and validate technical data: 0.5 FTE
• Cataloger or ILS administrator to review MARC mapping: 0.3 FTE
• Public services staff to review patron data: 0.2 FTE

If you don't have these resources, hire a consultant. Budget: $10-20K.

Timeline Estimate

6-12 weeks. Longer if data is messy or vendor is slow.

Phase 3: System Configuration (Months 3-7)

Timeline: 12-16 weeks. This is the longest phase.

What Happens

• New system is installed in test environment. Not production yet. Just a sandbox where you can break things.
• Rebuild all your policies: Circulation rules, fines, item types, patron types, custom fields. This is weeks of clicking through configuration screens with your vendor.
• Build custom reports: Your old system had 47 custom reports. New system doesn\'t have them. Build the critical ones. Accept that you're losing some.
• Integration testing: Does the new ILS talk to your WiFi system? Your payment processor? Your discovery layer? Test it.
• Staff training begins: IT staff in new system. This is where you spot configuration problems ("Wait, that's not how it should work").
• Multiple rounds of data loads: Load test data. Find problems. Fix problems. Load again.

The Gotchas

• Configuration isn't intuitive. New system does things differently from old system. Staff needs training. More training than you budgeted for.
• Custom features become negotiating points. You had a circulation rule in old system that new system doesn't natively support. Do you pay vendor $10K to build it? Or do you change your policy?
• Integration problems are real. Your discovery layer might not work with new ILS out of the box. Your payment processor might need reconfiguration. Each integration is another 2-4 week project.
• Staff training reveals design problems. You spent 4 weeks configuring something one way. Staff says "that's not how we work." Back to the drawing board.
• New system runs slow with large data. Test environment works fine with 10,000 records. Real environment has 300,000 records and performance is terrible. Vendor optimization work: 4-6 weeks.

Staffing Reality

You need:

• IT staff for system admin work: 0.8 FTE
• ILS administrator for configuration: 0.7 FTE
• Vendor project manager: 20-30 hours/week
• Consultant for complex work: $15-30K

Timeline Estimate

12-16 weeks. This is where most timelines slip. Configuration is underestimated.

Phase 4: Data Migration & Validation (Months 6-9)

Timeline: 8-12 weeks. Runs partially parallel with Phase 3.

What Happens

• Full data load into test environment: All your bibliographic records, patron records, holdings. This is the first moment you see your real data in the new system.
• Compare old vs. new: Pick 500 random records. Do they match in new system? Count items. Count patrons. Verify numbers match.
• Public Services staff validates patron data: Call test patrons. Verify addresses, phone numbers, account types match old system.
• Cataloging staff validates MARC: Search by title. Does it find the right record? Do searches work the same way?
• Identify missing data: Patron history didn't move. Some custom fields disappeared. Now you decide: can you live with it?
• Multiple test loads: Load data, find problems, fix mapping, reload. Repeat 3-4 times.
• Final cleanup: Remove test data. Prepare for production load.

The Gotchas

• Data loads fail spectacularly. 10,000 patron records load fine. 45,000 patron records hits timeout or memory limit. Vendor needs to optimize.
• Patron records lose information in migration. Phone number field exists in both systems but new system has different format. Result: every patron's phone is corrupted.
• Circulation history is truly gone. Old system stored all checkouts. New system only stores active checkouts. You've lost years of patron behavior data.
• Staffing is burned out by now. You're in month 6-8 of a 12-month project. People are tired. Mistakes happen.

Staffing Reality

You need:

• IT staff for load testing: 0.8 FTE
• Database admin for troubleshooting: 0.5 FTE
• Public Services staff for validation: 0.3 FTE per branch
• Cataloging staff for MARC validation: 0.4 FTE

Timeline Estimate

8-12 weeks. Often slips due to data problems discovered during validation.

Phase 5: Parallel Running (Months 8-10, Optional)

Timeline: 4-8 weeks. Skip this if you can't afford the downtime.

This is the safety net. Old system stays live. New system goes live read-only. Patrons can search new system, but all checkouts and holds go through old system. You're running two systems simultaneously.

What Happens

• New system is live but in read-only mode (or limited mode)
• Patrons and staff can access new system, find issues
• All actual transactions still go through old system
• Vendor fixes issues you discover
• Staff builds confidence in new system
• 4-6 week run, then full cutover

The Cost

Parallel running:

• Doubles vendor implementation costs: +$20-50K
• Adds 4-8 weeks to timeline
• Requires 0.5-1.0 FTE IT staff
• But prevents major cutover problems

Timeline Estimate

4-8 weeks. Or skip entirely if budget is tight.

Phase 6: Cutover (Month 10-11)

Timeline: 1-2 weeks of intense work.

What Happens

You pick a date. Usually a weekend or after hours. Here's what occurs in the next 48 hours:

• Hour 0: Old system is closed to patrons. Last data extract from old system.
• Hour 1-4: Final data load into new system. If this fails, you need a rollback plan.
• Hour 4-8: Validation: Did data load correctly? Check for common migration issues (duplicate records, missing data, character encoding errors). These may not be immediately visible without looking for them.
• Hour 8-16: Staff smoke testing: Can librarians do basic tasks?
• Hour 16-24: More validation. Spot checks. Identify and prioritize bugs by severity. Some issues won't be apparent until staff workflows run.
• Hour 24-48: System is ready or it's not. If ready, open to patrons.

The Gotchas

• Data load fails at the last moment. You discover a corruption issue 4 hours before patrons arrive. Do you delay opening or go live with broken data?
• Performance is terrible with full load. System worked fine with 100K records in testing. With 300K records live, it's slow.
• Staff discovers configuration errors during cutover. You configured circulation rules wrong. Staff can\'t check out books. You\'re live in 4 hours.
• Integrations fail. Your discovery layer doesn't talk to new ILS. Your WiFi authentication breaks. Your payment processor rejects transactions.
• Patron accounts are corrupted. Some patrons can't log in. Some have negative balances from failed data migration.

Contingency Planning

Before cutover, know:

• What do we do if cutover fails? (Rollback to old system? Delay opening?)
• How do we manually check out books for the first week if the system fails?
• Who's on-call for what hours post-cutover?
• What's the escalation path if something major breaks?
• When do we declare victory and can staff actually go home?

Staffing Reality

You need:

• Vendor project manager on-site or available 24/7: full time
• IT director on-site for cutover weekend: full time
• ILS admin on-site or available: full time
• IT staff on call: 2-3 people
• Senior public services staff available for questions: 2-3 people
• Management available for go/no-go decisions: 1 person

Timeline Estimate

48-72 hours of intense work. Then 2-4 weeks of high-support mode.

Phase 7: Post-Cutover Stabilization (Month 11-12)

Timeline: 4-6 weeks.

What Happens

• High support mode: Staff are confused about new system. Constant questions.
• Bug fixes: Discovered problems are fixed by vendor.
• Data cleanup: Patron accounts have wrong info. Manual fixes.
• Report rebuilding: Custom reports that didn't migrate are rebuilt.
• Staff training (real training now): Staff actually understand what they don't know. Training is targeted and helpful.
• Performance tuning: System is slow. Vendor optimizes queries and configurations.
• Integration fixes: Discovery layer and WiFi auth finally work reliably.

The Gotchas

• Staff resistance emerges. Old system had features staff loved. New system does it differently. Staff is frustrated.
• Patron confusion is real. Patrons expect the interface to work like the old one. It doesn't. You get complaints.
• Performance problems aren\'t resolved quickly. System is slow. Vendor says "this is normal." It\'s not. Months of back and forth.
• Vendor support quality drops post-cutover. Your project manager is gone. You're dealing with regular support team now. Response times slow down.
• Budget for this phase underestimated. You budgeted 2 weeks of IT staff time. Turns out you need 6 weeks.

Staffing Reality

You need:

• IT staff for ongoing support: 0.6 FTE
• ILS administrator for troubleshooting: 0.5 FTE
• Vendor escalation support: ongoing

Timeline Estimate

4-6 weeks. Then you're "done," though problems continue to emerge for months.

Real Example: 45,000-Patron Library Migration

A mid-size library (45K patrons, 500K items, 3 branches) migrated from Proprietary System A to Proprietary System B. Here's what actually happened:

Phase 1 (Planned: 6 weeks, Actual: 8 weeks)

Board approval took an extra 2 weeks because one board member wanted more information about data security during migration. They hired a consultant ($2K) to review data handling procedures. Time was extended but the board felt confident.

Phase 2 (Planned: 8 weeks, Actual: 12 weeks)

Vendor\'s data extract took 4 weeks instead of 2. When they provided it, 8,000 patron records were corrupted (bad character encoding). Library\'s IT director had to write a script to clean them. Takes 2 weeks. Then mapping exercise takes 4 weeks because they discovered old system had 23 custom item types that new system only partially supported.

Phase 3 (Planned: 14 weeks, Actual: 18 weeks)

New system\'s configuration interface was unintuitive. Vendor kept saying "you need to do X" and library kept discovering X didn\'t work as documented. Circulation policies took 6 weeks instead of 3. Discovery layer integration required custom API work: $8K from vendor. One integration vendor (payment processor) was unresponsive for 3 weeks, delaying cutover window.

Phase 4 (Planned: 10 weeks, Actual: 14 weeks)

Data validation revealed that 12,000 patron records had blank phone numbers (data entry gaps from 2015). Had to decide: leave them blank or flag for manual cleanup? Flagged for manual cleanup. That's 40 hours of manual work. Also discovered that holds queue from old system was not fully exportable. Lost 6 months of hold history.

Phase 5 (Planned: 6 weeks, Actual: 8 weeks)

Parallel running happened. Discovered that reporting interface was completely different. Staff had built custom reports with canned reports in old system. New system required learning SQL. Decided to postpone advanced reporting until post-cutover and relied on vendor's standard reports.

Phase 6 (Planned: 2 days, Actual: 3.5 days)

Cutover happened on a Saturday. Data load completed successfully at hour 6. But public services staff discovered that patron account lookups were slow (5-10 second wait per lookup). Turned out there was a missing database index. Vendor optimized at hour 18. Then checkout system had a bug where it was charging fines incorrectly. Hotfix deployed at hour 28. System was declared ready at hour 32. Patrons were told system would open 4 hours late on Sunday.

Phase 7 (Planned: 4 weeks, Actual: 8 weeks)

Staff training was more intensive than planned. IT director did 8 hours of training instead of budgeted 4. Took 2 weeks to get to "staff can handle basic operations." Then performance issues emerged. System was significantly slower than old system. Took vendor 4 weeks of optimization to get to acceptable speed. Post-cutover support costs exceeded budget by $12K.

Total Timeline

Planned: 12 months. Actual: 15.5 months.

Total Cost

• Vendor implementation: $85K (budgeted)
• Vendor extras (custom integration, hotfixes): $18K (not budgeted)
• Consultant fees: $12K (partially budgeted)
• Staff time (overtime): $22K (not budgeted)
• Discovery layer integration consultant: $8K (not budgeted)
• Total: $145K (budgeted $85K)

The Lesson

Even with experienced vendor and reasonably careful planning, migrations are complex. Expect:

• 3-4 month timeline slip
• 40-50% budget overrun
• Staff burnout
• Data problems you didn't anticipate

Hidden Costs: The Budget Killers

Staff Overtime

IT director: 4 weeks of 60-hour weeks during phases 5-7. That's 80 hours of overtime.

At $35/hour: $2,800 in overtime.

For multiple IT staff: could be $8-12K total.

Consultant Costs

Data migration complexity, integration troubleshooting, performance tuning. Budget: $15-30K.

Training Costs

Staff attending vendor training (travel, registration). Post-cutover training hours. Budget: $5-10K.

Temporary Closure or Reduced Hours

Many libraries close for 1 week during final cutover week. Lost revenue or service: $5-15K depending on library type.

Manual Workarounds

During the first month, some staff will manually do things (check books out on paper, process holds manually) when system is slow. That\'s hours of labor that isn\'t planned.

Third-Party Vendor Work

Your discovery layer vendor, authentication vendor, or payment processor might need to do custom work to integrate with new ILS. Budget: $10-25K per integration.

Decision Tree: ILS vs. Discovery System vs. Specialty Tools

Do You Need a Full ILS Migration?

Before you commit to 12 months and $100K+, ask:

Are you:

• At the end of vendor support (old system is no longer updated)?
• Paying significantly more than alternatives?
• Unable to do things your patrons need (mobile access, modern interface)?
• Losing staff because the system is too hard to use?

If yes to any of these, consider migration.

If you're mostly satisfied with current system but want to add features, consider:

• Discovery layer upgrade: Keep your ILS, just replace the patron-facing discovery interface. Cost: $20-40K. Timeline: 3-4 months. Less risky than full migration.
• Specialty tool integration: Add a single specialty tool (mobile app, patron portal, etc.) instead of replacing entire system. Cost: $10-25K.

Open-Source vs. Proprietary?

Proprietary (Vendor-hosted):

• Vendor does hosting, backups, updates
• You\'re trusting vendor\'s infrastructure
• Faster implementation (vendor has more professional services)
• More expensive: $40-60K per year

Open-Source (Koha, Evergreen):

• You host it or pay consultant to host
• More control, but more responsibility
• Slower implementation (community support, not enterprise support)
• Cheaper: $10-25K per year
• But requires staff expertise you might not have

Reality: For a 45K-patron library, proprietary is usually safer. You have budget to pay for support. Open-source makes sense if you have IT staff who know Linux and databases.

The Playbook Checklist - Use This To Take Control

Before You Start (Make These Decisions Yourself)

• Board approval of 12-month timeline and $100K+ budget. You justify this. Use the "Real Example" section below to show what went wrong elsewhere.
• Decision on parallel running (yes or no). You make this call based on your risk tolerance and budget. See Phase 5 details.
• IT director or consultant assigned to project. Non-negotiable. If you don't have an IT director, hire a consultant (budget $20-30K). This person owns technical success.
• Data audit planned (Phase 2). Start this immediately. You can\'t plan extraction if you don\'t know what you have.
• Contingency budget (at least 30% over estimate). This is not "nice to have." The "Real Example" shows 40% overrun is normal. Budget for it.

During Planning

• Vendor signed contract with timeline and deliverables
• Staff allocated to project
• Communication plan for patrons (explain what's happening)
• Decision on what data to keep vs. lose
• Rollback plan for cutover failure

During Implementation

• Monthly status updates to board
• Track actual timeline vs. planned (you'll be behind)
• Track costs vs. budget (you'll be over)
• Weekly vendor check-ins
• Monthly staff training

At Cutover

• 24/7 on-call schedule (at least 2 weeks post-cutover)
• Contingency plan activated if needed
• Documentation of what went wrong
• Post-mortem meeting planned for 1 month post-cutover

After Cutover

• Monthly "lessons learned" meetings for 3-6 months
• Performance monitoring for 6 months
• Staff satisfaction survey at 3 months and 6 months
• Documentation of customizations for next person who works on system

You Can Do This. Here's How.

The biggest lie vendors tell you is that migrations are their job and you're along for the ride. They\'re not. They're your job. The vendor is a contractor executing your plan.

This playbook exists because libraries that understand the phases, ask the right questions, and maintain control have better migrations. Libraries that trust the vendor timeline, skip the data audit, and minimize staff time get burned.

Read this again in 3 months when Phase 2 data extraction gets delayed. Read it again in month 8 when configuration takes longer than expected. Read it in month 11 when cutover hits snags.

Every library on the "Real Example" list thought this wouldn\'t happen to them. You don\'t have to be one of them. You have control here. Use it.

References & Further Reading

This article draws on the author's professional experience in library technology consulting. Where specific claims reference external sources, links are provided inline.

Related Reading

Deepen your understanding of vendor relationships and system choices:

• Data Extraction Survival Guide: What Actually Gets Stuck — The technical reality of getting your data back from a vendor before migration. Includes debugging strategies when vendors claim data can't be extracted.
• Open-Source Library Tech Evaluation Framework — When and how to choose open-source systems instead of proprietary ILS vendors. Cost-benefit analysis and implementation complexity.
• The Beginning of the End, Part 2: Contract Traps — Hidden clauses vendors bury in implementation contracts. What to negotiate before you sign.
• Small Library Tech Stack: What You Actually Need — Alternatives to massive migrations for libraries that don't need a full ILS overhaul.
• The Beginning of the End, Part 1: Baker & Taylor's Collapse — How we got into this situation. Understanding the broader vendor market consolidation context.