Moving P2P partner profiles from the NZ to the IZ
Problem: The NZ-managed partners have the same Codes as the equivalent partners in the RS Directory. This prevents an IZ from downloading the Directory partners until the NZ partners are removed.
Solution: To circumvent this roadblock, new NZ-managed partners will be created as temporary replacements. They will have new, unique codes that will not conflict with those in the directory. This will make the cleanup a longer process, but it prevents any service disruptions to your patrons (as well as with SUNY).
Initial Steps:
-
Create the new Replacement Partners in the NZ
-
As I mentioned, the only data that needs to be unique is the Code; make this unique in whatever way you like, as long as it doesn't match the Directory. But all other details within the partners can be identical to the current NZ partners.
-
Once they have been created, Distribute these Replacement partners to the IZs
-
After which, the IZs should update any/all Rota Templates, replacing the Original NZ partners with the Replacement partners
-
When the IZs are fully configured to use the Replacement partners, return to the NZ and mark the Original partners as Inactive, then Distribute the changes again
-
This is just an extra step to ensure that no new requests are created with these Original partners
At this point, all new incoming/outgoing requests will be using the Replacement partners. Since this is the case, you will be free to begin removing the Original partners piece-by-piece from all remaining Active requests. This process will take a while, as any request (Borrowing or Lending) that has one of these Original SUNY partners as the Active partner will need to finish organically, waiting for the patron to return the item and/or ship the item back to the lender. But it's at this point that the cleanup can begin.
Phase One Cleanup Steps:
-
Once you have confirmed that Replacement partners are all working as expected (and I see no reason why they wouldn't), Delete the Original partners from the NZ
-
This will behave just like your Sandbox test (removing the Original partners from some but not all IZs), but this is expected
-
Since the Replacement partners will are being used, there's no reason to let the Original partners linger once you start the cleanup phase
-
It is recommended to go one IZ at a time, one partner at a time
-
For example: start by removing SUNYBUF from American, and once that is done move on to SUNYALB, and so on
-
Begin removing the Original SUNY partners from active requests
-
To find the requests, you'll want to use Analytics to see all of them in one place
-
I recommend creating the Borrowing and Lending reports in the NZ, as then you can see all affected IZs in a single report
-
Lending Request Cleanup
-
This is very simple, as there is only one way to cleanup LRs: update the Request Status
-
The status of the requests needs to be one that Alma considers Inactive: Request Completed, Deleted, or any of the various Cancelled statuses
-
However, anything in a Rejected status is still considered semi-Active by Alma, so these will need to be updated
-
This will need to be done manually, in the Lending Requests Task List
-
Filter your results appropriately, expand the results to show 50 at a time, and you will be able to update requests in batches of 50 (there is no job that can do this in Alma)
-
Borrowing Request Cleanup
-
The same method used for Lending requests can be used, but there is a second option as well.
-
Instead, you can remove the Original SUNY partners from each BR's Rota
-
Active partners cannot be removed; only Pending and Rejected
-
This method, though, can only be one manually one request at a time, but allows you to cleanup the SUNY partners from any active BRs
-
Once one (or more) of the Original partners have been cleaned up from an IZ, run the Distribute job in the NZ once again
-
If all of the requests were cleaned up, that partner will be removed
-
If not, you'll see the same error message indicating if any Borrowing and/or Lending requests remain
This is effectively the entire process. Over time, clean up all of the Original partners as much as possible. As we discussed, a there will be requests that are still actively sharing with one of the SUNY partners, so we'll have to wait for these to finish via normal means. But, the upside is that once these requests finish, they won't need to be cleaned up - they'll be in the Completed status, so no longer active in the system.
Eventually, all traces of the Original SUNY partners will be removed, and they will finally be fully deleted. Once that has occurred, it's time for the next phase.
Phase Two Cleanup Steps:
-
Once you're ready to begin, this is where you'll finally create the IZ-managed partners, as desired
-
Since the Original NZ partners are now deleted, each IZ can download the SUNY partners from the Directory, as desired
-
And in doing so, any Rotas and Rules can be updated to use these Directory partners
-
Once the IZs have fully switched to using Directory partners, the Replacement partners can now be deleted
-
And this process will be identical to the removal of the Original partners
-
Use the same reports (updating the filters, of course), and follow the same methods to clean up any lingering requests that still have the Replacement partners on them
-
After that cleanup is done, they can be deleted just like the Original partners
Additional Notes:
-
Like we discussed, this is going to be a long process. This is mostly due to having to wait on some requests to finish organically before partners can be deleted. But the advantage to all of the extra steps means that there will be functionally no disruptions of service to any/all patrons. And your RS staff will see little-to-no difference in their day-to-day work.
-
Some requests might be troublesome - you can't find them when searching in Alma, they won't let you update their status, etc.
-
If these pop up, Ex Libris has methods to find and correct them, or just outright delete them if they are not needed
-
-
Lastly, I would not recommend bothering with this process in your PSBs.
-
If you don't need the PSBs for active Resource Sharing testing, it would be best to just wait for the August refresh, which will automatically copy Production settings to the PSBs
-
The "one IZ at a time, one partner at a time" method is for ease of tracking progress. By focusing on a single partner within a single IZ, you can fully complete the cleanup for that partner, then run the Distribute job to remove them, and then move on to the next partner on the list. But this is far from the only approach to this cleanup; this is just how I would approach the situation were I in your shoes.
In reality, this cleanup can be handled by whatever method is most convenient for you all. You could focus on only Borrowing first, then do Lending second. Or you could work on both at the same time. You could focus on cleaning up one IZ at a time, or you could handle it as one large project for the whole network. Each IZ could be in charge of their own cleanup, performing it as quickly or as slowly as they need, and it wouldn't affect any of the other IZs.