Data Cleanup Tasks from Alma Testing and Review
This page tracks data cleanup tasks identified during Alma testing, workflow review, training and other activities to prepare for go-live in July.
If you identify a data issue, please add a row to the table below. Fill out the first five columns.
If you are working on an identified issue, please use the last three columns to track the status.
Issue Reporter (include your name below) | Type of data (Configuration, Bibliographic, Holdings, Items, User, Fines, Loans, Requests, Licenses, Courses, Other) | Description of issue
| Where the issue needs to be fixed (Aleph, Alma, Both, Unsure) | When the issue needs to be fixed (prior to technical svcs freeze, prior to fulfillment freeze, after go-live ASAP, after go-live, unsure) | Who is working on issue (name of individual or department working on this) | Updates / additional information | Status (Pending, In Progress, Not Doing, Complete) |
|---|---|---|---|---|---|---|---|
@Erin Nettifee | Configuration | We need to remove the item statuses in duk50/tab15 for KUN51 for item statuses 60-62 so that they do not migrate to Alma. In Alma, we need to fix the item policy labeling for 59 (it came over as DVD Player) | Aleph & Alma | Prior to technical freeze | LSIS | 4-10-2025: Item status 60-62 have no active items or deleted items in Alma. Erin submitted a ticket to asktech@ with a plan to remove these.
3-14-2024: @Erin Nettifee has fixed the labeling for item policy 59 in Alma Production. | In progress |
@Erin Nettifee | Users | We will need to remove users who are patron type 19 - Special Collections. We are not able to remove them from Aleph prior to migration, so they will need to be purged after migration, because ExL can’t exempt specific user groups from migration. | Alma | After go-live |
|
|
|
@Erin Nettifee | Users | Remove dummy patron accounts (Aleph status 22) | Alma | After go-live |
|
|
|
@Erin Nettifee | Configuration | Remove patron status “guest” in Alma | Alma | After go-live | @Erin Nettifee | This can happen in Alma, so I am adjusting the where/when. |
|
@Erin Nettifee | Items | Remove BorrowDirect and TRLNDirect items that were on loan to patrons but the loan is closed out. (Item in BorrowDirect library, status is Item On Shelf). | Alma | After go-live |
| From Erin - Evaluate potential reporting needs - data could be exported before records are cleaned up. Needs more discussion. |
|
@Erin Nettifee | Items | Consider appropriate fix for BorrowDirect items that have no collection code in Aleph which means they migrate to “UNASSIGNED” as a location in Alma | Alma | After go-live |
| Fixing the issue in Aleph is not feasible - creating a collection code is simple, but we would have to then update existing records as well as the DB code that actually creates the item record from the NCIP call. |
|
@Jacquie Samples | Empty Holdings due to Transfers | When whole titles are transferred to the LSC, duplicate holdings records were created to move Items to, but the source holdings records were not always deleted. Deletion of “no longer active” (no items attached) is sometimes desired. | Alma | after go-live | MADS | We began this clean up in Aleph, but continuing in Alma is needed, especially as a check on lingering empty holdings. |
|
@Erin Nettifee | Users | The Alma migration automatically populates the patron purge date field with the same date as their account expiration. This is not ideal for a variety of reasons. Ex Libris may be able to turn off this migration for us, but if they can’t, we’ll need to run a user job to erase that field. See Basecamp post (must be project team member to view.) | Alma | After go-live | @Erin Nettifee | Steps to clean up:
| Pending |
@Erin Nettifee | Loans | Clean up ARCH and SCL transfer accounts in Aleph. The associated loans are super old and we don’t want them to migrate that way. This is something we should do now, and then check again closer to cutover to ensure nothing has accidentally gone in transit again. | Aleph | Prior to fulfillment freeze | @Erin Nettifee - I will work with Rubenstein to verify the status of the items and then clean up the transit account loans. | 1-19-2024: Erin has emailed lists of the relevant loans to Lauren Reno for review. Have emailed the list of the rare govdocs to asktech@ for review. | In Progress |
@Erin Nettifee | Loans | Clean up transit accounts for MCL, LAW, DIV, MUSIC, PERKN and LILLY. This is something we should do now in early spring, and then do again when we get close to cutover. At some point I assume we will stop putting items in transit prior to cutover, but we don’t know that date/time right now. | Aleph | Prior to fulfillment freeze | @Erin Nettifee , with representatives at CAST | 1-19-2024: Erin has shared snapshots of the relevant accounts with CAST members 5-8-2025 Still in Alma: Sanford, LSC, DOCS, Div, Archives, Ford, Lilly, Law, SCL, PERKN | In Progress |
@Julie Brannon | Vendors | Vendor Accounts The presence of information in the Aleph vendor “Account M” and “Account S” fields triggers the creation of a vendor “account” in Alma. When users create orders or invoices they have to select which vendor account to use if there is more than one. Is it ok to delete the account rows that were created because the migration found something in the Aleph Account M or Account S fields or is this useful info that we need to keep. Counts by library of active vendors that have info in the Account M or Account S fields: | Alma | Prior to technical svcs freeze | @Julie Brannon | 2/28 Update: Julie will work with ExLibris to determine the best cleanup approach in Alma. No action required from acquisitions staff at this time. 2/20/24 Sent separate emails to Penny and Angela at DUL Financial Services, Julie Harris at Ford, Sean Chen/Shyama Agrawal/Neal Fricks at Law, and Li Ma at MCL describing the issue. List of active vendors with info in either Aleph Account M or Account S fields: https://duke.box.com/s/dgabx3qvnnrtkarunlap9yfcieym2xqv
| In Progress |
@Julie Brannon | Subscriptions | Missing order numbers: 1555 Subscription records (Z16 table) don’t contain an order number value. At migration, Alma creates an order for any active subscriptions that aren’t linked to an order. From the migration documentation: "subscriptions from Aleph's Z16 (subscriptions) with no order reference and still active will be migrated as basic Alma orders since subscriptions are implemented as orders in Alma. It is recommended that Z16 active subscriptions are linked to Z68 orders prior to migration in Aleph as not doing so will yield Alma orders which, although will be waiting for renewal status upon migration, will require additional manual handling post-migration in order to continue working with those orders (for instance requiring adding mandatory funding and copies information which isn't managed on the Z16-level in Aleph, but is mandatory in Alma). | Aleph | Prior to technical svcs freeze | ERSA (for subscriptions owned by DUL) @Julie Brannon communicate to independent libraries | List of subscriptions: https://duke.box.com/s/l98zmw3zej0kcbf5jie0iq46zit6un25 Counts by sublibrary:  Update 5/26/24: We foud more by searching for subscriptsions with a blank space ' ' in the order number:https://duke.box.com/s/4bq4dc0nd7mf10q1q4v5i1eznkkyu1sx 
| DUL - In Progress LAW - Reviewing (Neal, Sean & Marsha) |
@Julie Brannon | Orders | Review migration rules for orders with $.00 in Aleph that aren’t gifts or deposits. These orders migrated to Alma with a price of $1.00. Do we want to do any cleanup in Aleph before they migrate again at cutover? From ExLibris: “Alma does not allow a zero amount for an order unless it is defined as Z68-METHOD-OF-AQUISITION = "G" or "D" or if the ACQ method is mapped in the Migration Form to GIFT/DEPOSITORY/LEGAL_DEPOSIT. If the amount is zero and the ACQ method is not mapped to GIFT/DEPOSITORY/LEGAL_DEPOSIT, the order amount is changed to 1.00 [at migration].” Note from Julie 3/21/24: On our migration form, we mapped G, ST, and T to “Gift” and “D” to Depository. Julie will run a report of orders that don’t have those 4 acquisition method values and are $0 orders. | Aleph if there is time before go-live |
| ERSA @Julie Brannon ask independent libraries | Notes from VM: probably the $.01 to $.01 is preferable, but Bethany and I can discuss and get back to you; a clean up will be needed either way. SC & MM: List above isn’t all gifts. Most of the LAW orders for periodicals have a $0.01 local price value. Reply from Julie - yes, that makes sense. We were confused about this review task and I ran an updated report (see “Description of issue” for explanation). Here’s the updated report: https://duke.box.com/s/g3l46c8n7g1fuqjsq820mgnr5r7q7z79 |
|
@Julie Brannon | Subscriptions | Missing Subscription renewal dates - we use invoice as source of truth. Need to investigate where the various renewals dates live in Alma. Alma: There’s a renewal date on the order and there’s a date interval (ex: 90 days). Alma can send notification to users to alert them to review it 30 days prior to the renewal date. We don’t have this functionality currently, so this is a lower priority. Order in Aleph has a renewal date, subscription doesn’t have a renewal. Next step: review a list of orders in Aleph that don’t have a renewal date on the order. | Aleph | After go-live | ERSA and independent libraries | Open orders with blank renewal dates: https://duke.box.com/s/3l6tot8rg49shzz418qfb46w384g43nf
| Pending |
@Julie Brannon | Orders | Order status cleanup:
Julie will confirm how the non ‘SV’ values “open” status values mapped to Alma and determine whether we need to do any cleanup in Aleph. Julie will look at a few in Alma to see how they migrated to determine the impact - are these still open? | Aleph | Prior to technical svcs freeze | ERSA and Mono Acq will each look at the ones for their areas. | Julie created an updated report for review: https://duke.box.com/s/8zfs8rq7bhhmo2vznjeyon5ioyte86g2 Question about Aleph: Is there a way to batch close or delete a set of orders? Bill talked to Heather from MADS and thinks there might be possibilities if we have a use case for this. MM/NF will review the LAWO orders (looking like 255 of 24345 records will need to be edited in ALEPH before hand) | Pending |
@Julie Brannon | Orders | Update Renewal dates - the migration process doesn't look at the order and that's our source of truth for renewal dates. Need to flip these dates via API after migration. 2/20/24 We can’t remember what this was?? Check meeting notes to trigger our memory? Migration process puts in a default renewal date? | Alma | After go-live | @Julie Brannon will try to dig into the migration process for this
|
| Pending |
@Julie Brannon | Orders | For standing and ongoing orders, we need to review the Acquisition Method values applied to orders in Aleph that are used to track additional information such as delayed publication or payment by credit card. Analysis notes are captured in this sheethttps://duke.box.com/s/qhwuh8vyaxmoac0qhm84i5pla4y42mge to determine which Acq Method values need to be updated to a new Acq Method in Aleph prior to migration. For example, “Approval” subscription orders that don’t require payment need to treated in Alma like Gifts, Exchanges, and Deposits. This could be met by migrating them with an acq method of “Technical.” Data cleanup/review is needed to determine which should be changed to type “Other” in Aleph so that they’ll migrate as “Technical.” | Aleph | Prior to technical freeze | ERSA, Independent Libraries (low volume for Ford and MCL) | See this folder report of all Aleph orders of type S and O with separate files for each library: https://duke.box.com/s/1srzc5hqdfq4f2lzxkk9ufuqiy2qb45w | In Progress |
@Julie Brannon | Subscriptions and Orders | Review of linking between subscriptions and orders is needed. ExLibris migrates subscriptions to Alma and links them to the order # that exists for that order in the Z16 subscriptions table. In practice, there can be multiple orders for a bib record over time, some of which are closed. Check-in notes might be captured on one of those closed orders and might not be the order that’s linked on the Z16. Identified an approach to streamline this review given the high volume of subscription records (39k total; 5k open orders). Virginia and Bethany suggested running two reports. Review both reports and work through whichever is shorter. (see updates/additional info column for report links)
|
|
|
| Pending | |
@Julie Brannon | E-resources | Unmigrated databases / e-collections clean-up
| 360 | Prior to technical svcs freeze | ERSA, Professional School Libraries
|
|
|
@Julie Brannon | E-resources | Unmigrated titles clean-up
| 360 | Prior to technical svcs freeze | ERSA, Professional School Libraries
|
|
|
@Julie Brannon | E-resources | Review title lists for databases for which all titles were activated to determine whether there are any concerns about these | 360 | Prior to technical svcs freeze | ERSA, Professional School Libraries
|
|
|
@Julie Brannon | E-resources | Unmigrated databases / e-collections clean-up
| Alma | After go-live | ERSA, Independent Libraries |
|
|
@Julie Brannon | E-resources | 360 deprecated databases cleanup. We can’t generate a list of these from within 360 and need ExLibris to provide a list so we can do cleanup within the KB. | 360 | Prior to technical freeze
| ERSA | ExLibris provided the list: https://duke.box.com/s/itou2wacqh5tomeew5da66jwgyeoqg7k | Pending |
@Julie Brannon | E-resources | Broken links: As part of the data review, we identified 4007 portfolios with an empty URL (broken links). Electronic Portfolio: URL = Empty | Alma | After go-live | ERSA | If an excel file is needed, it can be exported from the Alma result list page. (It was running for a long time, so Julie didn’t export and upload it to box) | Pending |
@Julie Brannon | E-resources | Suggested task from ExLibris: Review the ProQuest Enrichment Report. Review to confirm these are accurate to our subscriptions and if anything on this list seems inaccurate, contact our ProQuest Account Manager to see what ProQuest has listed as our subscriptions. ERSA reviewed the list of collections activated by the PQIS enrichment process and decided that it will be cleaner to NOT run this process during our go-live cutover since it will likely lead to a lot of confusing back and forth about the various collections. ERSA will take a closer look at the report and activate those in 360 if appropriate. | 360 | Prior to technical svcs freeze and after go-live | ERSA | Received an updated report from Chana on 4/5 after asking questions about the original report. | In Progress |
@Julie Brannon | E-resources | Spot check collection portfolio lists migrated/matched to Alma from 360. We need to determine how to perform some quality control on the lists that migrated/matched. | Alma | After go-live | ERSA | As an example, see the Testing Checklist provided by ExLibris Link resolver tab - we looked at title listing counts for 2 collections during data review in February. | Pending |
@Julie Brannon | E-resources | Set up all packages that require special parameters (such as O’Reilly) at cutover. | Alma | After cutover data review is complete (usually 2-3 days before go-live | Assigned a Project Plan task for this to Virginia Martin to “Update all linking parser parameters for e-resources that have custom links” on 7/9. |
| Scheduled for 7/9
|
@Erin Nettifee | Courses, Bibliographic | Brief records from the DUK30 migrated to Alma - these are old course reserve records that are no longer in use. We did not want to migrate courses records to Alma so this was not expected, but likely due to some missed nuance in understanding how the migration would work. UPDATE 4-17: Some of these records may be actively circulating - see DU065911M as example - needs more research | Alma | After go-live | MADS and @Erin Nettifee | Records cannot be exempted from migration. They can be identified from the prior system identifier field using an Analytics search (“ends in DUK30”). The plan is to suppress the records as quickly as possible, and then to work on cleanup post go-live. | Pending |
@Erin Nettifee | ILR, Bibliographic | Lots of DUK40 records migrated to Alma. We need to make sure they are suppressed, and then identify cleanup opportunities | Alma | After go-live ASAP | MADS, @Erin Nettifee | Looking at suppressing records first. | Pending |
@Erin Nettifee | Users | Review and remove any DKU users that were loaded |
|
|
|
|
|
@Erin Nettifee | Users | In Aleph we have two user groups for TRLN visitors (14 and 17) and one user group for TRLN system accounts (37). So we need to create a new user group for BorrowDirect onsite visitors and transfer any migrated patrons from Aleph to that patron group so that they get more correct borrowing rules. | Alma | after go-live ASAP | @Erin Nettifee | We can do the setting piece of it before we migrate to Alma, but we need to learn more about resource sharing rules and requirements, which has not yet happened with Ex Libris, so this task is pending that work. | Pending |
@Julie Brannon | Items linked to Orders | In Aleph, there are cases where up to, in one example, 2829 items with unrelated bibs/titles all contain the same order number in the Z30 item table. I ran a report to try to provide some examples - not sure what caused this or how to identify what the correct order number should be for these records. Financial transactions seem to be unaffected. In Alma, if a user tries to view one of these orders the system becomes unresponsive because it’s trying to display a table list of all ordered items. | Aleph | Prior to technical svcs freeze if we want to prevent loading this potentially erroneous data to Alma. | TBD. Julie needs to set up time to meet with MADS to review. |
| https://duke.box.com/s/1srzc5hqdfq4f2lzxkk9ufuqiy2qb45w |
@Erin Nettifee | Items | Several hundred items migrated to Alma with incorrect item policy values of ‘00’, ‘1' and ‘PK’. This was flagged by Alma’s health check dashboard | Aleph | Prior to technical services freeze | MADS | Ticket has been submitted with relevant data to Asktech - 13557107 | In progress |
@Erin Nettifee | Users | Some users in Aleph have more than one netid listed as an identifier on their record (ID type 3.) When we try to sync those users to Alma from their info in identity management, the sync will fail if their correct netid is not the first netid that was picked up by Ex Libris in the migration. Fixing the issue in Alma will require creating a new patron record with the correct patron identifier and then merging the incorrect record into the new record. It’s unclear how big a scope of issue this is - a test run of ~2,000 records uncovered two - but we should try to fix it in Aleph if possible since merging the records will have to be done one by one. | Unsure | Prior to fulfillment freeze | TBD | We may be able to get an actual output file to identify these by running a full SIS import to Alma - the report out of the integration will tell us which records failed, and then we can clean them up in Aleph. | In progress |
Issues that are either complete or we decided we were not going to do
Issue Reporter (include your name below) | Type of data (Configuration, Bibliographic, Holdings, Items, User, Fines, Loans, Requests, Licenses, Courses, Other) | Description of issue
| Where the issue needs to be fixed (Aleph, Alma, Both, Unsure) | When the issue needs to be fixed (prior to technical svcs freeze, prior to fulfillment freeze, after go-live ASAP, after go-live, unsure) | Who is working on issue (name of individual or department working on this) | Updates / additional information | Status (Pending, In Progress, Not Doing, Complete) |
|---|---|---|---|---|---|---|---|
@Erin Nettifee | Holdings | Cleanup records that had erroneous data in 852b field that generated extra libraries in Alma during initial migration. | Aleph | Prior to technical freeze | MADS and @Matthew Harrington | This has been completed. | Complete |
@Erin Nettifee | Fines | The data migration shows that we have a number of quite large credits that were generated by operator error (e.g., copy/paste a 9 digit number into the sum field.) These will need to be cleaned up in Aleph to prevent them from migrating as open credits to Alma | Aleph | Prior to fulfillment freeze | @Erin Nettifee | We will have to identify and waive these credits post Alma final delivery, prior Alma cutover. This task is on the cutover migration plan.
| Complete |
@Erin Nettifee | Items | We had ~200 items that migrated from Aleph to Alma that were previously on New & Noteworthy but never had their Aleph item temporary location flag cleared. That resulted in them migrating to Alma with a permanent location of New & Noteworthy and a temporary location of Stacks or Reserves, which is the opposite of what should happen. | Aleph | after go live ASAP | MADS | Erin has reported the issue to AskTech for MADS - ticket 13502024 - atten @Jacquie Samples
5-8-2025: There are approximately ~18 items still in this state but it looks like the original group reported is cleaned up, so I am going to mark this as complete - Erin | Complete |
@Jacquie Samples | Bibliographic, Portfolio, | Merge 360MARC BIB to P2E related portfolios | Alma | After go-live | MADS in consultation with ERSA | The P2E process created portfolio records for many of our e-resources, but may have not connected them to the correct bibliographic records, especially for “zero-title” 360 Databases. For go-live, the 360MARC records will have collection titles in 915 fields which will be used to link back to the portfolios as needed. The scope of this project is somewhat unknown until we can view the results of the P2E process in June/July. Some test data had the 915, but many did not. No Longer Needed Based on P2E decision to exclude 360MARC | Not doing. |
@Erin Nettifee | Fines | We have some libraries in Aleph that charge handling fees of $0 (Goodson, others?). Because they are charged and remain open, they migrate to Alma even though no money is owed. We should consider trying to clean these up. | Unsure | Unsure | @Erin Nettifee | These were cleaned up in February 2025 prior to finally enabling the automated bursar integration | Complete |
@Julie Brannon | Orders | Orders with blank Vendor codes: 1335 order records are missing a vendor code value. This triggers a reject of the order during migration, so we need to add vendor codes if we still need those orders to migrate to Alma. DUL plans to ignore these since most have status of CNB - likely old migrated orders from ENNIPAC. Julie will provide the list to the prof schools to review | Aleph | Won’t do | @Julie Brannon Share with independent libraries to make them aware of thes rejected vendors. | List of orders: https://duke.box.com/s/ucnwq2n6smssnpeyumxq4jall7w9fzoq Counts by library
| Complete (won’t do) |
@Erin Nettifee | Users | Suffix users coming in via Identity Management (JR, III, etc.) have the suffix map to the first name field. This is because in Aleph we map the full name field as LAST, FIRST, SUFFIX and the Alma migration mapping was LAST, FIRST This results in an Aleph patron of SMITH, JOHN, III mapping to Alma as First name: John III Last name: Smith | Unsure | after go-live ASAP | @Erin Nettifee | The run of the full patron load showed that it will overwrite the erroneously loaded names, so we will just need to ensure that that loading of a full synchronized file happens prior to go live on the 10th. Suffix is included in the patron loader, so it should map correctly. | Complete |
@Erin Nettifee | Users | Clean up users where the name field mapped entirely to Alma “last name” - that means that the migration script couldn’t parse the name o the last name and first name fields. Some of these accounts could probably be cleaned out of Aleph prior to fulfillment freeze - old test and dummy accounts are definitely on the list. ~700 accounts are part of this. | Both | After go-live ASAP | @Erin Nettifee | 3-6-2024: Reviewed data from Analytics, corrected Aleph names for unexpired accounts. Deleted several accounts, probably could delete a lot more. But the most immediate cleanup issue is probably taken care of. | Complete |
@Erin Nettifee | Fines | The data migration shows that we have a number of quite large credits that were generated by operator error (e.g., copy/paste a 9 digit number into the sum field.) These will need to be cleaned up in Aleph to prevent them from migrating as open credits to Alma | Aleph | Prior to fulfillment freeze | @Erin Nettifee | We will have to identify and waive these credits post Alma final delivery, prior Alma cutover. This task is on the cutover migration plan.
| Complete |
@Erin Nettifee | Configuration | The terms of use and fulfillment rule names came in with awkward naming because we did not understand how it would migrate. E.g., they put the loan length before the patron group and and then if the rule also included an item policy they put the item policy after the patron group, so we ended up with things like “7 days Faculty Seven Days.” Both the terms of use and the fulfillment policies need to be cleaned up. | Alma | After go-live | Erin | We’ve done pretty significant cleanup of the terms of use and fulfillment policies, so I am declaring this as complete. | Complete |
@Erin Nettifee | Users | We have ~95 “Friends of the Library for Life” in Alma who were created with user expiration dates many decades in the future. This list should be reviewed to determine which patrons have passed away and can have their accounts cleaned up and removed. | Unsure | Unsure | Erin and ADS | List was reviewed by library development and accounts for those who have passed away were removed from Aleph. | Complete |
@Julie Brannon | Items | Anything suppressed at the item level in Aleph was migrated to Alma with a status of “Technical Review.” Need to make independent libraries aware of this in case they need to do anything with those records in Alma. | Alma | After go-live? |
| 4-10-2025 We’ve used Alma now long enough that we can consider this complete, even though we didn’t confirm how this was done at the cutover date. | Complete
|