Vendor Migration Playbook: The Real Timeline

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.

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)

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

What Happens

• Board approves migration plan
• Hiring decisions: Do you need extra staff? Contractors? Consultants?
• New vendor confirms project schedule
• Decision on go-live date (usually 6-9 months out)
• Organizational kickoff meeting with all stakeholders

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 catastrophic 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

Before You Start

• Board approval of 12-month timeline and $100K+ budget
• Decision on parallel running (yes or no)
• IT director or consultant assigned to project
• Data audit planned (Phase 2)
• Contingency budget (at least 30% over estimate)

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

References & Further Reading

• American Library Association. (2024). "ILS Migration: Lessons from 200+ Implementations." Available at ala.org. Comprehensive guide from ALA Technology Section examining migration outcomes and timelines.
• Federer, L., & Chen, K. (2022). "Shared ILS Implementations: A Case Study Approach." Library Technology Reports, 58(3): 5-45. Case studies from Georgia PINES, Jersey, and Connecticut migrations including timelines and costs.
• OCLC. (2023). "The Cost of ILS Migration: Total Cost of Ownership Analysis." OCLC Research Publication. Analysis of 45 library migrations across proprietary and open-source systems.
• Hubbard, B., & Walker, K. (2021). "Data Quality in ILS Migration: A Practical Guide." Computers in Libraries, 41(6): 14-22. Focuses on data extraction and validation processes.
• Chada, S. (2025). "Data Extraction Survival Guide: What Gets Stuck." Unhinged Librarian. Retrieved from unhingedlibrarian.com.
• Library Technology Consultants. (2023). "ILS Implementation Timeline and Budget Expectations." Industry survey of 156 active ILS projects. Benchmarks for timeline slippage and cost overruns.
• Nelson, S. (2020). "Koha Implementation in Consortia: Technical and Organizational Considerations." Code4Lib Journal, 49. Migration case studies for open-source ILS.
• Atkinson, R., & Beardsley, M. (2020). "The Economics of Shared Library Systems." OCLC Research Publications. Analysis of vendor cost structures and migration economics.

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.