Alma and Discovery Cutover Process

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

Cutover to Alma is the process by which the following occur:

Your institution stops using the current library management systems
Data is migrated a final time and moved to the Alma cloud
Full publishing/refresh of Primo/Primo Central based on the production data from Alma is performed
Your institution begins working productively in Alma.

This process represents several key steps and involves certain preparations in order to smoothly transition to Alma. This document reviews the approach and steps of this process.

In general, the Alma cutover period and structure has three key goals:

The technical freeze can be extended beyond 7-10 days if data extracts, mapping and validation take a long time. The Clarivate project team will re-validate the data and alert you about any problem which may require data re-extraction.

Keep patron-facing services up and running with no/minimal interruption
Keep the freeze of each institution’s back-office technical services work to a minimum (usually beginning 7-10 days prior to Cutover start).
Leverage the technical services freeze to allow the organization to provide its staff training in Alma and Alma/Primo.

Your Alma project manager will provide a specific cutover plan that details the key steps and milestones for this important period.

The following is a typical cutover timeline:

Prepare for Cutover

The preparation phase (usually starting in the weeks preceding the technical freeze) leading up to the cutover involves a few key steps whose execution ensures a smooth transition. They include the following:

Ensuring that the latest migration forms/inputs and P2E file have been prepared and that any data rejects from test load are handled in your source system/s, if necessary.

For Aleph, Voyager and Verde migrations; your test load migration form is upgraded to the latest version automatically and populated with your baseline answers from test load along with the latest information from your system. This is the starting point to complete and finalize the migration form to use during cutover.

For Non-Ex Libris system migrations, download the latest form from here and complete the cutover forms based on the latest version.

Double-checking to ensure that all libraries, locations, and vendors that may exist in the final ILS data are reflected in Alma with the same codes. See below.
Reviewing Alma Go-Live readiness checklist and ensure Day-1 needed functions are working per the functional workflows that your Ex Libris project team has worked with you to set up and test during implementation
Ensuring any new library, location, or vendor added since test load to your current systems have been added also to Alma.
Ensuring that no major new changes or data types are introduced in your source systems or data provided that would risk the final cutover process.
Continuing planning the process of updating any/all electronic data requesters/suppliers to use the Primo service page as a resolver link target instead of your current link resolver system. Additionally, any Z39.50 requesters/suppliers to which you provide services to must be coordinated as well. This must be effective from the Primo Go-Live date only and not before.
Planning updates to library staff and patrons regarding any changes in URL access or library schedule or service during the cutover period.

Cutover Preparation and Approach for Third-Parties that are Provided Library Data and Services

Many external (non-Primo) third-party providers (for example, Google Scholar, Ebsco, RefWorksetc.) target your library resources in your current library systems (Before Alma). These include electronic access where current openURL, base URL syntaxes, and icons are registered with the search provider who offers link resolving services for your licensed e-material. They also include sites that search your library and catalog resources via protocols such as Z39.50.

Upon Go-Live, it is crucial that these external parties be updated regarding the change of address in order to continue to search and provide relevant services. Alternatively, some sites follow a more sophisticated approach using and maintaining their own URL redirect tools. More information regarding sites who implemented such a solution can be found in the following location:

https://developers.exlibrisgroup.com/blog/Alma-link-resolver-set-it-and-forget-it

Link Resolving - For sites not implementing their own solutions, the third-parties should be instructed to point the base URLs, link syntaxes, and icons to Alma. Do not point them before Go-Live, since delivery and Primo are still being provided based on the old systems. For Google scholar, if you have an existing Google Scholar account, it is recommended that you set a new test-restricted label for testing purposes, so that you can distinguish between your old and new system resolving. Following verification post Go-Live, change the label to the active one your patrons will access and retire the old account.

The URL of Alma-Primo’s base services page is:

http://<primo server host:port>/openurl/<primo institution code>/<primo view_code>?

The URL of Primo VE’s base services page is:

https://<Primo server host>/discovery/openurl?institution=<Primo institution code>&vid=<Primo view code>

The URL of Alma-Summon’s base services page is:

https://<Alma domain>/discovery/openurl?institution=<Alma institution code>&vid=<view id>

Third Party Vendor Integrations - In addition to notifying vendors about changes to the base URL for the link resolver, all third-parties that have any type of integration with Alma should be notified of the upcoming base URL change, including those for EOD and EDI.

Alma’s default View It icon is located at:

https://<Alma domain>.exlibrisgroup.com/view/link_resolver.gif

Do not shut down your previous link resolver system immediately after cutover because:

It takes time to contact the known external search providers and have them update the relevant link information.
It takes time to determine which unknown external search providers link to your link resolver data and have them update the relevant link information.

The following is the recommended method for handling the cutover from your link resolver system to Alma:

Based on our best practice, leave the link resolver system up and running temporarily for one month after Go-Live as a fallback for delivery purposes for all non-Primo discovery providers.
Update the providers during that month-long period (including those based on incoming requests to your link resolver system for providers of which you are not aware) in order to ensure that the new Alma URLs are on file with all of the providers, so that they are linked to Alma instead of your previous link resolver system.
Since all updates to E-resources occur only in Alma after Go-Live, it is recommended to complete the vendor updates as quickly as possible.
Search Providing (Z39.50) - the third-parties (such as other catalogs, RefWorks, etc.) should be instructed to point to your institution’s Alma base URL and port (210) immediately upon Go-Live, similar to the procedure for link resolving described above.

Unfulfilled Hold Requests

Since hold requests that are not yet tied to an item and patron on a hold shelf are not migrated to Alma, it is recommended to keep the number of unfulfilled hold requests to a minimum at the time of your cutover to Alma. This keeps any potential need for manual request recreation in Alma to a bare minimum.

Primary Alma Cutover Steps

Technical Services Freeze

Technical services freeze is the period of time whereby the library ceases any updates to its catalog/inventory, electronic-resources, and acquisitions and course data to ensure that all data is brought over in full to Alma – as these areas are not brought over to Alma again (neither in full nor via incremental updates for changes done after the technical service cutover freeze begins –with one exceptional case). Once work ceases in these areas, the cutover officially begins.

For Ex Libris systems, it is recommended to perform a backup and to disable all jobs immediately preceding the freeze. After the extract portion of the ETL step is completed, the circulation-oriented jobs may be re-enabled.

Although fulfillment data (patrons, loans, and requests) is migrated again in full near the end of the cutover period just preceding Go-Live, fulfillment data is also extracted/migrated at the beginning of the cutover along with the other technical services data in order to facilitate final testing on complete data.

Data ETL (Extract, Transform, Load)

Data is extracted from your source system and securely sent by FTP to the Alma cloud. Depending on the source system, the Extract and Transform steps may be done by Ex Libris or may be done by the migrating institution. Loading to the Alma environment is always done by Ex Libris. The following chart details this division of responsibility:

Source System	Extract	Transform
Aleph Extract/Transform for Ex Libris hosted and cohort implementing libraries is performed by Ex Libris.	AutoExtract (Library)	AutoExtract (Library) Update Ex Libris when completed
Voyager Extract/Transform for Ex Libris hosted and cohort implementing libraries is performed by Ex Libris.	AutoExtract (Library)	AutoExtract (Library) Update Ex Libris when completed
Non-Ex Libris systems	Library Update Ex Libris when completed	Ex Libris
SFX Extract/Transform for Ex Libris hosted and cohort implementing libraries is performed by Ex Libris.	AutoExtract (Library)	AutoExtract (Library) Update Ex Libris when completed
Verde Extract/Transform for Ex Libris hosted and cohort implementing libraries is performed by Ex Libris.	AutoExtract (Library)	AutoExtract (Library) Update Ex Libris when completed
360 Counter/Intota Assessment Extract/Transform for Ex Libris hosted and cohort implementing libraries is performed by Ex Libris.	AutoExtract (Library)	AutoExtract (Library) Update Ex Libris when completed
UStat	Ex Libris	Ex Libris

Network Zone – Central Bibliographic Catalog - Consortium

For consortia, the network zone is typically refreshed/built at the beginning of the cutover in order to link all members’ bibliographic records to the central catalog. This is generally done in one of two ways:

The institution provides the full set of de-duplicated bibliographic records. The institutional members link to these records.
The institution contracts with Ex Libris to build a central set of de-duplicated bibliographic records. The institutional members are matched and linked to these records.

Your Alma Environment During Cutover

Alma Configuration Freeze

On the day of the source system technical services freeze, the configuration freeze starts in Alma as well. From that time, until the clean data is delivered back on Production and you have reviewed and accepted the final data for Go-Live, no new changes will be retained in Alma. This is necessary as the institution’s full data and configuration is copied from Production to an Alma migration staging environment where all data in your Alma environment is refreshed based on the most recent source data. This data is then copied back to production, thus overriding the previous production institution used during implementation, while retaining only the configuration that existed at the start of the freeze.

This Alma configuration freeze is an ideal opportunity to train library staff on a transient sandbox-like Alma production environment until the clean data and configuration is passed back to production for final checks. Once clean data is passed back to production and the data has been reviewed and accepted, it is recommended that any updates done in Alma be minimal and targeted and set as read-only as much as possible, as any change (other than loans, hold-shelf requests, and patrons without staff roles) from that point will remain in Alma after Go-Live.

Data and Configuration Elements Retained at Cutover

There are four areas of data migration that are tightly connected to the configuration elements of Alma and do not change frequently. Therefore, they are only migrated from the source systems once (during the test load) and are retained like standard configuration. These areas are:

Libraries
Locations
Vendors, Vendor Interfaces
Resource sharing partners

For these core data areas, it is mandatory that any change done to a library, location, vendor / vendor interfaces, or Resource sharing partners after the test load (at the inception of the Alma implementation process) that are needed in Alma after cutover be done in both the source system and in Alma throughout the implementation period. As noted above, as part of the preparation for the cutover, it should be confirmed that all needed changes to these four areas, if any, are reflected in Alma.

Vendors that were deactivated (changed to Inactive status) in Alma between testload and cutover can still have orders and invoices attached/linked to them during the cutover load.

Certain configuration is not retained during cutover since it is associated directly with the data which is refreshed at cutover. Examples of configuration which are not retained are:

sets, since the values in the sets are data elements which are not retained
online services order (for discovery display), since the specified services are activations which are not retained
cloud app configurations are not retained

All other configurations done in Alma during implementation are retained through cutover to Go-Live. This includes, but is not limited to:

modifications to letters and notices
templates
normalization and indication rules
logical sets (itemized sets are removed)

Optionally, the following additional data areas may be requested from your Ex Libris project manager to retain from your implemented data prior to cutover start. By default, and if not requested prior to cutover, these areas are cleaned in addition to the other data areas:

Funds: Funds are not retained if customer is migrating new acquisitions (orders/invoices) at cutover.
Licenses (without relationship to e-inventory)
Courses and reading lists (without Bib citations)

For certain specific configuration elements and in order to ensure data consistency between your original system’s codes and the data that uses those codes, the following elements are retained, but may be merged with Alma’s setup in these areas (if they are not already in your Alma setup):

Reporting Codes (acquisitions)
Fund Types (funds)
Fiscal Period (funds)
Item Policies (inventory)
User Groups (patrons)
User Identifier Types (patrons)
Block definitions (patrons)
User Statistics Categories (patrons)
Academic departments for courses (courses)

Alma meta-collections are not retained at cutover. They are considered bibliographic records and so are cleaned by migration cleanup programs. They have to be added again after cutover load. Any configuration that is linked to these mandatory collection assignments (such as digitization profile rules and digital import profiles) do not display any collection. Alma collections need to be created and selected again in the configuration.

Reports created in Analytics during the testing period are not affected by the cutover.

Alma scheduled jobs are disabled during cutover to avoid any unwanted actions or data changes done before Go-Live on the final clean data. Any job that may need to be run during cutover is done ad-hoc if needed, (for instance, publishing to Primo and offline circulation) while the job scheduling for ongoing jobs is only re-enabled at Go-Live by your Ex Libris Project team.

Users at cutover

Users added during implementation and/or migrated during test load are not retained unless:

The users are non-public - this includes Staff and Contacts. All non-public users are retained. You may change a previously loaded Public user to a Staff user using an API, but this user may not then be updated again at cutover. If a Public user is changed to a Staff user, and then a record with the same PrimaryID is loaded, the incoming patron will be rejected. In other words, if you change a Public user to a Staff user, this user will not be updated with new information at Cutover.

When the above situation happens, where a public patron is changed to Staff and therefore it cannot be updated at cutover, the rejection message in the patron reject report reads 'Transaction silently rolled back because it has been marked as rollback-only'

The users are Public migrated users and have a staff-oriented role (a role other than ‘patron’). In this case, when migrating patrons at cutover, the staff roles associated with a Public user are retained. The rest of the user’s information is refreshed with the new migrated patron data by matching on the previously loaded Primary ID. It is important, therefore, that the Primary ID of users does not change between testload and cutover, if you wish to retain staff roles for Public users.

If such a public/patron user in Alma does not have a matching ID with one of the migrated patrons, the patron and their roles are removed from Alma.The above information regarding user retention is only relevant if patrons will be re-loaded at cutover. If patrons are not migrated during any load, then all patrons that were created during the testing period will be retained between test load and cutover.

Test Final Data – Delivered back on Production

The goal of this step is to ensure that the final “clean” data has come over in an acceptable manner. It is expected that this “clean” data will be checked in a cautious manner before Go-Live since any changes or tests done at this stage are retained through Go-Live (with the exception of fulfillment data for patrons, loans, and on hold-shelf requests, which is typically re-loaded a final time at the fulfillment cutover and is cleared and overridden one last time). Other types of data changes, including requests other than hold-shelf requests, are not overridden at fulfillment cutover.

As part of the checks, Primo is checked with this final production data as well in the same cautious manner.

Primo – Alma Cutover Activities

Publish / Load Pipe

Upon clean data arrival on Production during cutover, your data and Primo central availability information is published and loaded into Primo. If there are other data sources in Primo other than Alma, those should be loaded as well.

Check Data in Primo/Alma

For information, see Test Final Data.

Summon – Alma Cutover Activities

The Summon-Alma Cutover Processes includes the following:

Purging current source ILS bibliographic data from the Summon Index
Updating Summon with the final Alma data after the Alma data has been reviewed and accepted

Summon Indexing takes approximately five to seven days to complete. Alma-Summon customers will need to extend their Fulfillment freeze for one week after Alma data acceptance or Go-Live with Alma (and then go live with Summon approximately two weeks later). Final confirmation of going live in the new Summon environment is sent to you by the project manager.

Fulfillment/Circulation Freeze

Fulfillment/circulation freeze is the period of time near the end of the cutover whereby the library ceases any updates to their patrons, loans, and request records in the source system to ensure that all relevant data is brought over in full to Alma, since this is the final time that this data is brought from the source system. Once this freeze begins, it is recommended to put the previous system/s set to read-only mode (and/or effectively becomes read-only) and will not be updated again. Any changes in the system after this point are not brought to Alma, although circulation charge and discharge activity do not need to stop during this period. For more information, see Offline Circulation File.

Fulfillment Load

Fulfillment data is extracted from your source system and securely sent by FTP to the Alma cloud, in the same way that the test and cutover data was delivered and loaded.

ONLY fulfillment data is updated; very specifically, anything related to the item is not updated, including circulation counts such as the number of times an item has been circulated. The item status which indicates if an item is on loan is updated.

There can be no configuration updates between cutover and fulfillment load. The migration form and field mapping form and structure of the files must be exactly the same as the cutover. The only point of fulfillment load is to re-load the updated fulfillment data in exactly the same way as cutover.

Courses during fulfillment load

Course Instructors which are linked to the user file via the internal User ID must be updated during the Fufillment Load, since the User ID may change with the re-load of patrons. The loader attempts to update the internal User ID based on the username and/or original ID, therefore it is important that you do not change the mapping of the Primary ID.

Offline Circulation File

Depending on the volume of circulation in the source system and the number of days between the fulfillment cutover and the Go-Live for your particular project schedule, it may be necessary for the library to continue to perform loan / return activity in the final hours/days before Go-Live and after the source system is already in read-only mode (when fulfillment /circulation freeze begins).

In such cases, the institution uses the Offline circulation client which ensures there is no downtime from the perspective of the library’s end-users. The client is available for download from Alma for Fulfillment administrators (instructions in Alma OLH).

This client tracks four key pieces of information:

What date/time the transaction took place
Whether the transaction was a loan or a return
The patron’s ID (usually patron barcode or username)
The item’s ID (item barcode)

That information is stored in a delimited text file which is loaded into Alma immediately prior to Go-Live and after fulfillment cutover data is loaded to Alma in order to reflect the most recent circulation loan activity and item availability right before all new fulfillment activity and transactions begin only in Alma.

The offline circulation file is stored in the following format:

Col.1 = date (YYYYMMDDHHMM) [12 chars] +L (Loan) or R (Return) [1 char] + item-barcode [80 chars]

Col.2 = patron ID

For example:

201401011239L33031245 howdy.doody

The Offline circulation file is uploaded to Alma via the Alma user interface by a fulfillment administrator via Fulfillment > Advanced Tools > OffLine Circulation.

Unfulfilled Hold Requests and Historical Loan Information

Hold requests that are not attended to (fulfilled) in the source system by the fulfillment cutover freeze, that is items not yet transferred to the hold shelf on the patron’s behalf, are not migrated (see above). However, for Ex Libris ILS systems, a csv report is provided at the time of the fulfillment cutover of these remaining unfulfilled holds if this information is needed for reference/re-creation purposes.

Active loans are migrated to Alma, as well as item-level historical loan counts (where relevant), while historical loan transactions are not. However, for Ex Libris ILS systems, a csv report is provided at the time of fulfillment cutover with all historical loan transactions stored in those systems in case this information is needed for reference or external reporting purposes in the future.

Go-Live

The following sections describe what happens when the migration team runs the go-live process.

Unscrub Emails/FTP

Throughout implementation, all migrated email or FTP addresses are scrubbed/anonymized to ensure no stray communications are sent to external parties during testing. Only explicitly defined allowed email and s/ftp addresses can be used. All addresses are unscrubbed/unanonymized upon Go-Live in coordination with your Ex Libris project management team and email restrictions are removed.

The following categories of emails are included, if applicable:

Public patrons
Non-public patrons
Vendors
FTP addresses
Resource Sharing Partners

Enable Job Schedule

The Alma job schedule is re-enabled upon Go-live by your Ex Libris project team. See above.

Enable Authority Preferred Term Correction

During implementation, the ongoing preferred term correction updates that transfer the latest authority record information and update the linked bibliographic records are disabled. These updates are not necessary, since the source system is assumed to have a baseline of corrected bibliographic headings that only need be updated later in Alma post Go-Live.

If your site is interested in having ongoing preferred term headings updates, contact your Ex Libris project manager prior to your cutover.

Acquisition Solr indexing/save

Solr indexing and save are enabled for PO Lines during the go-live job. These are customer parameters: acquisition_solr_indexing_enabled and acquisition_solr_save_enabled

Not included in Go-Live

When data is loaded to the Production environment, any webhooks that are set up are set to inactive. The Go-Live job does not set these to active, so they should be manually set to active after go-live.

Post Go-Live

Complete Publish to External Parties

If you publish your data and holdings to an external party such as OCLC, Libraries Australia, COPAC, SunCat, HathiTrust, and Google Scholar, it is recommended to do so upon Go-Live.

Load Local Authorities

If local authorities were implemented at your site and are needed in addition to the global authority records and types that the Community Zone contains, you can load your local Authorities again at this stage. Any local authorities created during implementation were removed during the cutover process along with other data loads and tests done during implementation.

Finalize Link Resolver Move

Finalize the link resolver move by performing the steps described in Cutover Preparation and Approach for Third-Parties that are Provided Library Data and Services.

Appendixes

Appendix – Large Consortium “Big Bang” Approach

When large centrally managed consortia move to Alma as part of one implementation (Big-Bang approach), Ex Libris’ primary goal is to minimize any impact of services for all consortial institutions during cutover. A small number of larger high-volume institutions that use a broader range of functions and facilities in Alma are typically moved to Alma before the smaller institutions. Circulation/fulfillment and end-user Discovery will effectively have no downtime at all during the cut over period while switching from the old ILS to Alma. The secondary goal is to expose any potential issues as early as possible in the cutover process.

It is therefore recommended that the institutions of the consortium be handled in clusters for the cutover period. Grouping the institutions into clusters and staggering them over a period of ~12-14 days per cluster allows the institutions to gradually move their activities from the old systems to Alma and Go-Live. The network zone for the consortial catalog is typically built at the beginning of cut over period in conjunction with the first cluster.

Ex Libris uses the cluster approach as the cutover methodology for consortia for three main reasons:

There are dependencies between the activities to be performed during cutover; therefore, not everything can be done in parallel for all sites. Defining clusters enables Ex Libris to make best use of the time needed and reduce downtime for individual sites to a minimum.
All testing and configuration is performed before cutover starts. However, experiences from other projects have shown that the first weeks after going live are very intensive and require a lot of attention and internal support from the consortial service center. The cluster approach addresses this fact by not sending all libraries into production on the same day. Going live gradually enables the central project team to focus on the major sites first and to benefit from all questions and cases that may occur for the next cluster of libraries.
Using the cluster approach allows Ex Libris to ensure the “onboarding” of new large consortia does not impact the rest of the institutions sharing the Alma multi-tenant environment.

General Alma Cutover Milestones Per Cluster

Cutover Day 0: Technical services freeze begins and ETL process ensues
Note: New Cataloging /Acquisitions work ceases in source ILS, Circulation continues as normal
Cutover Day 7-11: Clean migrated data delivered for final checks on the production environments of Alma and Primo
Cutover Day 12: Cataloguing and Acquisition staff start targeted work in Alma
Cutover Day 12: Circulation services go to off-line mode (using the Ex Libris Offline circulation client)
Cutover Day 13-14: Final Circulation data loaded to Alma, Offline Circulation transactions loaded to Alma
Cutover Day 14: Full Go-Live with Alma + Primo

Cluster	Institution Types
Cluster 1	Represents a small number of large/high activity institution
Cluster 2	Represents a medium number of medium/small activity institutions
Cluster 3	Represents a large number of small activity institutions

The clusters are composed as described above in order to minimize the impact of services for larger institutions. Even within a cluster, libraries may go live gradually as soon as their data is ready.

The actual number of clusters and institution types and the duration may vary from consortium to consortium.

Since many consortia work with a central bibliographic catalog before migrating to Alma and since managing synchronization updates between the source ILS system and Alma for *existing* records (once Cluster 1 begins the move to Alma – whereby Cluster 1’s migration populates all/most of the Network Zone Bibliographic records for ALL institutions) is not feasible in this timeframe, the following work assumptions /recommendations should go into effect for the smaller subsequent cluster institutions as soon as Cluster 1 freezes technical services at the beginning of Week 1:

Updates to *existing* bibliographic records in the source ILS system are frozen for Clusters 2 and 3 until their Go-Lives in Alma (for example, fixing/cataloging existing records). Once Cluster 1 Goes Live, updates to existing bibliographic records may proceed for all clusters in the Alma NZ directly. Those changes are reflected in the Alma/Primo of those institutions that have gone Live already.
*New* bibliographic records (for example, for newly acquired material that arrives during the cutover period of a subsequent cluster) can be added to the source ILS system before that cluster’s technical freeze.

For Cluster 2 (until Cluster 2’s Technical freeze at end of week 2)
For Cluster 3 (until Cluster 3’s Technical freeze at beginning of week 4).

Any new bibliographic record added by subsequent clusters after Cluster 1’s technical freeze must be provided independently and is appended to the Alma NZ during each of those cluster’s respective migration cutovers.

Any work on holdings and items as well as any institution-specific data in the migration scope (for example, orders, loans, patrons) can continue to be updated in the source ILS system (with no dependency on other clusters) until the technical freezes noted in the Alma cutover milestones above.
Primo for each institution not yet live in Alma continues to function alongside the source ILS until that institution’s Go-Live – at which point it begins to work with Alma and join the Primo consortial catalog.
During cutover, institutions not yet migrated on Production will re-direct all Network zone communication with a Network Zone copy until their clean data is provided. At that point, their clean institutional data will be linked to the clean Network Zone. This is done to facilitate staff training/testing without compromising the clean Network Zone data.

After clean data is provided during cutover, but before Go-Live, staff must be careful with data updates, as the data worked on from that point is the clean data, which will remain in Alma post Go-Live.

The following plan may give an illustration of the availability of the main services for the different clusters according to the information above in a 3-cluster approach.

Appendix – Large Volume of Borrowed ILL/RS Items During Cutover

For institutions with an exceptionally high volume of resource sharing/ILL borrowing requests, where large numbers of new bibliographic records and temp/stub items are created after the technical freeze starts in the source ILS system, there may be a need to manage these new item additions to Alma after the technical freeze starts and before Go-Live to ensure that these items and their relevant loan transactions are accounted for. In such a case, and only in such a case, the following is the recommendation for handling.

Continue to create temp/stub items and bibliographic records for purposes of ILL/RS borrowing up until the circulation freeze
Manually track the IDs of the temporary items, temporary bibliographic records, and the associated patron IDs that loaned them
Load the temp BIBs to Alma after receiving clean data for confirmation on the PROD environment.

Using the MD import profile of type “Inventory” for new records only (no match/merge)
Provide a bibliographic file in MARC XML or binary format for the new bibliographic records added since technical freeze.

Mandatory tags:

BIB Title
Item information with location and item barcode (indicating in the profile in which fields the location code and barcode will reside)

Perform the following steps:

Create an ILLcirc.dat file with the relevant ILL/RS transactions from the IDs that you tracked in the format of the offline circulation file which includes all loan transactions performed for these new items between technical freeze and fulfillment/circulation freeze. Stop registering the ILL circulation transactions once the fulfillment/circulation freeze starts.
Start using Alma offline circulation client for all loan/return transactions upon fulfillment/circulation freeze.
Load the ILLcirc.dat file to Alma just prior to loading the regular offline circulation file.

Load the regular offline circulation file to Alma immediately before Go-Live.