Frequently Asked Questions

Amazon EC2 is a virtual server running in the cloud. It is the computer that runs your Koha system, but instead of sitting in your building, it runs in Amazon's data center.

Why it matters: You can choose the size of the server based on your needs and change it later if needed.

Application Load Balancer (ALB) is a service that distributes web traffic across one or more servers.

Why it matters: In Enterprise-style deployments, it can help route users to healthy servers and reduce disruption when one server has a problem.

Auto Scaling adjusts the number of servers based on demand.

Why it matters: It can help a library handle busy periods without keeping extra servers running all the time. Limits can also be set to help control costs.

Multi-AZ means using more than one AWS data center location within the same region.

Why it matters: This can reduce the risk that a single infrastructure issue takes the whole system offline. It is most relevant for libraries that want stronger reliability and recovery options.

Amazon Aurora is a managed database service used to store catalog, patron, and circulation data.

Why it matters: It can offer stronger backup and recovery options, and may improve performance for larger or more demanding deployments.

Amazon EFS is shared cloud storage that can be used by multiple servers at the same time.

Why it matters: In more advanced deployments, it helps keep files available across multiple servers without manually copying them between instances.

CloudFormation is AWS automation that helps build the cloud setup for your Koha system from a template.

Why it matters: It reduces manual setup work and makes deployments more repeatable. It does not remove the need to choose your settings carefully, and libraries without AWS experience may still prefer Managed Services or setup help.

High availability design means using a cloud setup intended to reduce downtime risk by avoiding a single point of failure.

Why it matters: Enterprise uses multiple components and multiple data centers so that one failure is less likely to take the whole system offline. This is most useful for libraries that need stronger reliability during busy periods or extended service hours.

Koha is an open-source Integrated Library System (ILS) used by libraries around the world. It supports cataloging, circulation, patron management, acquisitions, serials, reporting, and a public catalog (OPAC).

Why libraries choose it: Koha is flexible, standards-based, and not tied to a single software vendor.

Koha is open-source, which means libraries are not tied to a proprietary software license or closed data format.

• No vendor lock-in: Your data can be exported in standard formats.
• Flexible hosting choices: Self-service, managed, or community-supported approaches are possible.
• Strong library standards support: MARC, Z39.50, SIP2, and other common library standards are supported.
• Customizable: Libraries can tailor workflows, reports, and the patron interface.

Koha includes professional cataloging tools for day-to-day library work:

• MARC21 and UNIMARC support
• Z39.50 and SRU copy cataloging
• Authority control
• Item-level records for copies, barcodes, and locations
• Batch import and export tools
• Duplicate detection and record editing tools

Koha supports the main circulation workflows libraries expect:

• Check-out and check-in
• Holds and renewals
• Overdues, fines, and patron notices
• Configurable circulation rules by item type, patron category, and branch
• Offline circulation options

Koha's OPAC gives patrons a browser-based way to search and manage their library account.

• Search by keyword, author, title, subject, ISBN, and more
• View checkouts, holds, and fines
• Renew items online
• Create reading lists and saved searches
• Use the catalog on phones, tablets, and desktops
• Work in multiple languages

Yes. Koha includes acquisitions features for ordering, fund tracking, vendors, receiving, and invoice-related workflows.

Koha includes a serials module that supports subscription tracking, issue prediction, check-in, routing, and holdings display.

Koha supports built-in reports, custom SQL reports, and export options for further analysis. Libraries can use it for circulation reporting, collection statistics, patron trends, acquisitions, and more.

Yes. Koha supports common integration standards and interfaces such as SIP2, REST APIs, Z39.50, LDAP/SSO-related methods, and metadata exchange tools.

Koha has a large international community with documentation, mailing lists, community discussions, conferences, and commercial service providers.

Your total cost has two parts:

• KohaSupport software subscription: Billed through AWS Marketplace.
• AWS infrastructure: Billed by AWS for the servers, storage, networking, and any AWS services you use.

Important: Standard 30-day trials cover KohaSupport software charges during the trial period. AWS infrastructure charges still apply.

Yes. Standard Self-Service is the annual self-service software subscription for libraries running Koha live in their own AWS account.

Flexible AWS Marketplace usage-based billing may be available for eligible deployments, but the main public Standard offer is annual.

Common ways libraries manage costs include:

• Starting with the smallest practical deployment
• Using hourly billing when capacity may change
• Turning off non-production environments when not needed
• Setting budgets and billing alerts in AWS
• Choosing Standard instead of Enterprise unless stronger reliability is truly needed

AWS costs depend on the services and capacity you use. This can include servers, storage, networking, and any additional AWS services used by the deployment.

All usage is visible in the AWS billing console, which helps with budget tracking and cost review.

Billing for KohaSupport subscriptions is handled through AWS Marketplace, using the payment and billing arrangements attached to your AWS account.

AWS provides billing and cost tools such as the Billing Console, Cost Explorer, and budget alerts. These can help you monitor usage and identify unexpected charges early.

Enterprise environments with Auto Scaling are planned case by case. The right billing model depends on your architecture, expected demand, and uptime requirements.

If your institution expects variable capacity or strict uptime needs, talk with KohaSupport before finalizing Enterprise pricing.

Your total cost has two distinct parts:

• KohaSupport AMI license — charged per running instance through AWS Marketplace (hourly or annual). This is the KohaSupport subscription charge.
• AWS infrastructure — charged by AWS for the servers (EC2), storage (EBS, EFS), networking, and any additional AWS services your deployment uses (such as Aurora or an Application Load Balancer in Enterprise setups).

Both charges are visible in the AWS billing console, so you have full transparency over what you are spending and where.

Worth noting: Many libraries find that moving to cloud hosting reduces or eliminates on-premise costs — such as server hardware, maintenance contracts, and backup infrastructure — which can offset some or all of the AWS costs.

Enterprise is for libraries that need stronger reliability, clearer recovery options, and better support for busy periods than a single-server setup can provide.

Standard is a good fit for many libraries. Enterprise becomes more relevant when downtime risk, heavier traffic, or operational resilience matter more.

Enterprise is often a better fit for universities, consortia, large public library systems, and libraries with multiple branches or high-traffic online services.

It can also make sense for institutions that want stronger backup, failover, and recovery options than a simpler self-service deployment.

Enterprise uses a more resilient cloud design that can include multiple servers, multiple data centers, stronger recovery options, and infrastructure that can respond better during busy periods.

The exact behavior depends on the deployment architecture and AWS services used, so Enterprise should be evaluated based on your library’s operational needs rather than on a single feature list.

Yes. Many libraries begin with Standard and move to Enterprise later if they need stronger reliability, higher capacity, or a more resilient setup.

The best migration path depends on your current deployment, billing model, and data volume, so it is worth discussing before making the change.

A simple way to frame Enterprise is this: it is not about extra software features, but about stronger operational resilience.

Enterprise may be worth considering when your library wants to reduce downtime risk, improve recovery options, and avoid relying on a single server for critical services.

If you continue using the product after the trial period, the AWS Marketplace subscription moves to the paid pricing model for that tier. AWS infrastructure charges continue separately based on usage.

If you do not want to continue, review your AWS Marketplace subscription and AWS resources before the trial ends.

You can start with self-service, even if your team is new to AWS, and add help where needed.

KohaSupport offers optional services for libraries that want guidance with choosing the right deployment, launching Koha in their AWS account, setting up backups and secure access, planning migration, training staff, and preparing for go-live. Managed Services is available separately for libraries that want a more guided rollout.

Some AWS familiarity is helpful. CloudFormation reduces the amount of manual setup, but your library still needs to make infrastructure choices such as region, instance size, and deployment tier.

If your library wants help with those decisions, Managed Services is available separately.

Initial deployment is usually measured in minutes rather than days, but exact timing depends on the tier and AWS services involved.

Self-service can be quick for libraries with AWS familiarity. Managed deployments may take longer because they include planning, configuration, and optional migration or training.

Yes. KohaSupport can assist with migration planning and implementation.

A typical migration involves exporting data from the existing system, importing it into the new deployment, validating results, and planning a cutover. The exact approach depends on your current system, data quality, and timeline requirements.

Migration timelines vary depending on the source system, data quality, customization, and how much testing is required.

Smaller or simpler migrations may be completed relatively quickly, while larger or more customized projects can take longer. KohaSupport can provide a more realistic estimate after reviewing your current system and data.

Migration can often be planned from major library systems and legacy systems, but the best approach depends on the source system, export options, and data quality. KohaSupport can review your current environment and advise on the next step.

Start with New to AWS? How Koha on AWS works for libraries if your library wants a plain-language overview before choosing a path. It explains what AWS means in practice, what your library still needs to decide, and when to use self-service or ask for help.

Read Who handles what? Self-Service, Managed Services, and AWS responsibilities for a clear breakdown of ownership, billing, launch work, and support boundaries.

Yes. See Migrating to Koha from another library system for a practical overview of what gets migrated, the typical sequence, common risks, and when Managed Services is worth adding.

Your data is stored in your own AWS account, in the AWS location you choose for the deployment.

Why it matters: Your library keeps ownership of the environment, visibility into billing, and control over where data is hosted.

AWS provides security features such as encryption, access controls, and network isolation, and KohaSupport is designed to use those capabilities in a way that supports library deployments.

Actual security depends on configuration choices, operational practices, and who has access to the environment. Libraries with stricter requirements may prefer Managed Services or a separate security review.

Backup approaches differ by tier and deployment design.

Single-server setups typically rely on scheduled backups and snapshots. Enterprise setups can include stronger recovery options, depending on the architecture used. If backup retention or recovery objectives are important for your library, they should be confirmed before go-live.

Standard: These use simpler single-server designs, so recovery may require manual intervention or redeployment.

Enterprise: Enterprise is designed with recovery and failover options that can reduce disruption when something goes wrong, but behavior depends on the specific architecture and the type of failure.

Yes. Koha is open-source software, so libraries can adjust workflows, settings, themes, plugins, and integrations depending on their skills and deployment model.

Standard: These use simpler single-server architectures, so availability depends heavily on maintenance practices, monitoring, and how quickly issues are addressed.

Enterprise: Enterprise is designed for higher availability using a more resilient cloud architecture, but no specific uptime commitment should be assumed unless it is stated in a separate written agreement.

Standard Self-Service are self-guided by default.

Libraries can add separately scoped help for setup, migration, training, consulting, or managed services where needed. Existing Free subscribers moving to Standard can request complimentary migration assistance only; the Standard software subscription, AWS infrastructure, training, and ongoing support remain separate. Enterprise support arrangements depend on the implementation approach chosen.

Yes. Training can be provided as a separate service and may include staff onboarding, administrator guidance, and workflow-specific sessions.

Yes. A library can start with a self-service deployment and later engage KohaSupport for migration help, a guided launch, or ongoing managed services.